On 02/14/2011 11:43 AM, Oliver Kowalke wrote:
Am 14.02.2011 19:56, schrieb Jeremy Maitin-Shepard:
I do not think that a general signal handling library, while potentially useful, is required for Boost.Process to do asynchronous waiting. The reason is that simply letting two independent pieces of code be notified of SIGCHLD is not sufficient, because (in order to be efficient) the SIGCHLD handler needs to then invoke waitpid(-1, ...), which affects the global state of the program. Instead, what is needed is basically a SIGCHLD library, which allows registering a callback to be invoked when a given PID changes state (exited, suspended, or continued). There should be an option to invoke the callback directly in the signal handler, and there should also be a way (possibly built on top of the first invocation method) to invoke a callback asynchronously using ASIO. Ideally, Boost.Process could use this SIGCHLD library by default, but also be able to work with an alternate SIGCHLD multiplexing library.
This would require that the thread executing async. waiting of boost.process has to block all signals except SIGCHLD and the other thread handling the other signals must block SIGCHLD and unblock signals of interest (SIGTERM, SIGINT, ...). Other worker-threads have to block all signals. Wouldn't be the async. waiting of boost.process be a subset of the signalling library?
I don't think a dedicated thread is necessarily needed at all for SIGCHLD. Instead, at any point in the program that needs to fork(), use this sequence: block SIGCHLD in current thread wait until a lock is obtained on a signal-safe mutex (the SIGCHLD handler will also wait to lock the safe mutex; this cannot deadlock, since the mutex is only locked by threads that have blocked SIGCHLD) fork() add child pid to data structure containing the notification list for the SIGCHLD handler unlock mutex reset SIGCHLD blocked status SIGCHLD handler will repeatedly invoke waitpid(-1, &status, WNOHANG | WUNTRACED | WCONTINUED), and then invoke any registered handlers. These handlers need to be designed to be able to run from a signal handler in an arbitrary thread. If a handler needs to run outside of the signal handler context, something like ASIO can be notified to invoke the handler later.