On 02/14/2011 01:26 PM, Oliver Kowalke wrote:
Am 14.02.2011 22:02, schrieb Jeremy Maitin-Shepard:
On 02/14/2011 01:00 PM, Jeremy Maitin-Shepard wrote:
On 02/14/2011 12:50 PM, Oliver Kowalke wrote:
Am 14.02.2011 21:14, schrieb Jeremy Maitin-Shepard:
SIGCHLD handler will repeatedly invoke waitpid(-1, &status, WNOHANG | WUNTRACED | WCONTINUED), and then invoke any registered handlers.
why polling - it waists CPU cycles? I expect that the thread waiting for child processes state change blocks (gets suspended) until it is notified by the kernel that something has happened. other worker-thread do other stuff like communicating with other process etc.
It wouldn't poll indefinitely, as that would lock up the thread in which the signal handler was invoked. It is simply invoked repeatedly until the error ECHILD (meaning no more unwaited-for children) is returned. The notification is in the form of SIGCHLD, but that just means one or more children need to be waited on.
maybe you misunderstood my concerns. as I wrote in my previous posts - we have two possibilities in a multi-threaded env.:
1.) for each child process a thread is created calling waitpid() with the pid of the forked process only and returning the child state via a future
2.) only one thread is created dealing with the status of child processes - it calls sigwait() with SIGCHLD unblocked and waitpid(-1, & status, WNOHANG | WUNTRACED | WCONTINUED) until waitpid() returns ECHILD
I've some concerns if boost.process would implement the second point because it is a subset of the functionality of a boost library dealing with delivered signals (as SIGUSR1, etc.).
There is a third possibility, which is what I was referring to in my previous message: no additional threads are created to handle SIGCHLD and instead SIGCHLD is handled in any thread that does not block it (the user is expected to leave it unblocked in at least one thread). This would have the lowest overhead, I believe, and therefore be the best option to use, and it also would not require any coordination as far as signal handling with the rest of the program (but of course would require coordination as far as waitpid), except that it will manage SIGCHLD (but monopolizing SIGCHLD and calling waitpid go hand in hand).