On 02/14/2011 05:07 PM, Oliver Kowalke wrote:
Am 14.02.2011 22:51, schrieb Jeremy Maitin-Shepard:
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).
The SIGCHLD signal would be delivered to only one of the threads and you don't know to which one. you would have to install in all threads the same code.
Yes, it would be delivered to an arbitrary thread, but as signal handler settings are shared between threads, it would only be necessary to call signal/sigaction once.