|
From: Shane B. <ast...@te...> - 2003-06-18 23:57:46
|
You are awesome, thank you. Even the first chapter, on processes has told
me more than 8 hours searching the web with various results that don't help.
These PDF's are definately good for anyone interested in advanced POSIX
standard programming.
That said, I would like to get a little feedback, from what I've read, to
see if I am understanding correctly how it works.
I'll use my real situation for an example. I have a process, which fork's
itself into a daemon type process already, very old code that has been
through 15 programmers and has ended in my hands to clean up and make more
efficient. Within the code, I will periodically delete an entire SQL table,
and reimport the data from a memory resident version, which will have
various updates, new records, deleted records, etc. Directly accessing the
database, with what optimizations I have put in, still takes approximately
21 seconds to handle just the smaller of two tables like this.
My solution to this, not knowing anything about multi-threading, was to try
threads. First, I thought it might be possible to thread off the main
process which may already be running fork'd as a daemon, to fork and wait
for a SIGCHLD to be raised, I see where my error in thinking was. Signals
are not used like a message pump, I didn't realize that, as such my idea was
flawed.
After reading a few pages of the process PDF, I came to a new conclusion,
and would like to see if I am correct.
When I start the program, it runs as normal, forks off, etc. When I need to
save the database, after I dump the import.sql file, I should fork(), and as
long as it returns > 0, use exec to transform the child copy of the big
program, and run another script or program which handles the importing soley
itself. As such, the main application should not need any database access
method.
Is this correct usage of forking? How do I know when the transform'd child
is done, if the original process continues processing? This is where I
thought SIGCHLD came into play, you would catch the signal and have the
process call wait() since it should be done, and ready to clean up more or
less instantly, right?
If someone has been through this process before, I'd appreciate an idea on
how to make sure the original process knows the thread dumping the database
is done. I will keep reading, there is a lot of advanced material here, but
hopefully someone can help with some simple little code snippet.
Thanks,
-Shane
p.s. This world of multi-threading... wow, I ignored IPC for such a long
time... big mistake.
This list rules, thanks for the help!
----- Original Message -----
From: "Abhijit Shylanath" <mu...@gm...>
To: "Shane Bryldt" <ast...@te...>; "C++"
<dev...@li...>
Sent: Tuesday, June 17, 2003 3:38 PM
Subject: RE: [Dev-C++] Threading in FreeBSD
>
> Greets, Shane.
>
> > foobar**24
>
> I don't know about FreeBSD, but there's a really good free E-book on Linux
> programming:
> http://www.advancedlinuxprogramming.com/
>
> Chapters 3, 4 and 5 should be of interest to you - they're about
processes,
> threads and interprocess communication respectively.
>
> The other chapters are pretty useful and interesting in their own right.
> HTH.
> ________________________________________
>
> Abhijit Shylanath
> http://mudeth.tripod.com/
>
>
|