On Mon, Apr 09, 2007 at 01:40:06PM -0700, Darrin Chandler wrote: > On Mon, Apr 09, 2007 at 09:10:39PM +0100, Brian Candler wrote: > > I'm not saying that anything is actually wrong with the code you've > > provided; rather, that it's difficult for me to understand the subtleties > > involved in asynchronous signal-driven programming. And that's with a copy > > of the Stevens book beside me :-) > > If you have the Stevens book (APUE, I assume), and you're already into > threads, reread the part talking about how to simplify your program > logic with threads. I don't have it here, so I can't give you a > chapter/section. But the idea is to put things in a thread so that your > calls become synchronous/blocking. I believe the APUE example was a > reader thread and a writer thread for a socket, with each using blocking > read/write calls. As long as you don't add more complexity from thread > sync, this can be a win.
Right book (although unfortunately I have only the first edition). I think I'm trying to do exactly what you say: - one thread blocks on waitpid() waiting for a child to die - second thread does interesting work, and starts workers when it thinks it's a good idea (e.g. system is getting "busy") The issue, as I tried to describe in my original posting, is that if thread one blocks on waitpid(), as soon as it returns with the PID and status of a child, the second thread may fork a process with the same PID. I therefore could end up having a data structure containing two children with the same PID, one recently died (but not yet removed from the data structure), and one recently forked. Or actually, my existing data structure could end up losing track of one child. The purpose of this post was trying to determine a good way to avoid that. Regards, Brian.
