On 02/15/2011 10:19 AM, Oliver Kowalke wrote:
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,...).
The only way to wake up the event loop, as far as I know, is to change the status of a file descriptor. (The signal itself might cause a wake-up, but I don't think there is any race-free way to rely on that.) I suppose your claim is that if all the signal handler is doing is simply notifying asio that a signal arrived, then it might as well be done using a generic signal handling library. That is valid, but it is still an implementation detail, and therefore isn't really a concern. Doing it in the signal handler has the advantage of keeping the SIGCHLD handling relatively independent from asio. For instance, it would then be possible to support a combination of synchronous and asynchronous waiting, and also perhaps allow interoperability with other libraries that want to manage processes. It would require testing to know, but I'm not convinced that doing this work in the signal handler would add significant latency, e.g. more than would be introduced by random kernel interrupt handlers, and if latency is very important in certain threads, SIGCHLD (and all other signals) could simply be blocked in those threads. The documentation could warn about this.