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: Jeremy Maitin-Shepard (jeremy_at_[hidden])
Date: 2011-02-14 13:56:00

On 02/14/2011 08:14 AM, Oliver Kowalke wrote:
> Am 14.02.2011 16:45, schrieb Klaim - Joël Lamotte:
>> As far as I know, from a previous discussion on this list, async_wait
>> might
>> be the only (cross-platform) way (without having to add another
>> dependency
>> than boost to the project...) to achive the last point, knowing when the
>> child process ends.
>
> Do you mean with async_wait the feature dealing with SIGCHLD and
> sigwait()? If so it is not cross-platform. As discussed in this thread
> waiting on signals asynchronously influences the application and other
> libs - see installing signal handlers.
> IMHO waiting on signals (SIGCHLD, SIGTERM, SIGSTOP, SIGUSR1, ...) should
> be implemented in a separate library.

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.

>
>> About the "thread and future + sync. waiting" way of doing it : would it
>> work with any kind of child process end (including any kind of crash)? Or
>> is it part of the limitations you're thinking about?
>
> Yes - waitpid( child_pid, ...) blocking in one separate thread -
> returning the result in a future. Depending on how many threads are
> created blocking in waitpid it may reduce the performance (at least at
> some amount of threads the scheduling overhead may become significant).

In addition to the overhead of one thread per process (which is rather 
substantial overhead), there is the problem that all other code running 
in the same process is forced to use this same inefficient waiting 
mechanism, as opposed to a multiplexing interface as described above. 
For instance, glib has a similar SIGCHLD handling facility, and while I 
believe it would be possible to have Boost.Process make use of it, the 
inefficient waiting scheme would not inter-operate with the process 
launching facility in glib.