Am 15.02.2011 19:10, schrieb Jeremy Maitin-Shepard:
On 02/14/2011 11:12 PM, Oliver Kowalke wrote:
Arguably then the signal handler could record that the signal was delivered rather than actually call waitpid. In any case, waitpid won't block, so I expect the signal handler would take on the order of a millisecond (this would really have to be tested, though, to know).
Also, the user could still provide a dedicated thread by blocking SIGCHLD in every thread but one, without any special support in boost.process.
If you call waitpid(-1,...) in aloop inside a signal handler, then you get the pids of the children. What do you do next? Keep in mind that the functions you can call must be obstruction-free/async-safe. How do you tell the other threads your pid you got from waitpid()?
The status for each child could be written to a designated pre-allocated data structure, and the thread could be notified by writing a single byte in non-blocking mode to a designated pipe. If the write fails because the pipe buffer is full, it isn't a problem, because it means the reader end has yet to receive some previous notifications and will therefore still see the new status.
Seams not reasonable for me - too much overhead. The only possible way would be using a atomic variable which will be set by the signals handler that a SIGCHLD was delivered and the other threads running through a event-loop will detect the change of the atomic variable and then one thread would loop over waitpid( -1,...).