Re: [boost] [Boost-users] Brainstorming [WAS: Subject: Formal Review of Proposed Boost.Process library starts tomorrow]

Subject: Re: [boost] [Boost-users] Brainstorming [WAS: Subject: Formal Review of Proposed Boost.Process library starts tomorrow]
From: Oliver Kowalke (k-oli_at_[hidden])
Date: 2011-02-14 14:43:12

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?