Re: [boost] [gsoc] Boost.Process done

Subject: Re: [boost] [gsoc] Boost.Process done
From: Jeremy Maitin-Shepard (jeremy_at_[hidden])
Date: 2010-09-11 15:18:39

On 09/11/2010 10:12 AM, Boris Schaeling wrote:
> On Sat, 11 Sep 2010 00:02:38 +0200, Jeremy Maitin-Shepard
> <jeremy_at_[hidden]> wrote:
>
>> [...]implementing the communication. (Probably it would make sense to
>> implement signal handling support as a general asio facility.)
>
> There is a Boost.Asio extension for signal handling in Trac:
> <https://svn.boost.org/trac/boost/ticket/2879>
>
> Actually there are two extensions. While mine follows Boost.Asio
> patterns more closely I remember that Dmitry pointed out some issues
> with the current implementation (see
> <http://thread.gmane.org/gmane.comp.lib.boost.devel/201581/focus=201923>).
> The main problem with his solution is that it doesn't support
> synchronous wait operations. Apart from that his implementation seems to
> be more lightweight. As I didn't look into the issues yet Dmitry had
> mentioned I wouldn't recommend anyone to use my Boost.Asio extension
> currently.

Note that there are some additional non-POSIX facilities available that 
may be of use in implementing signal handling:

- Since Linux kernel 2.6.22 and glibc 2.8, there is eventfd and signalfd.

- On BSD (including Mac OS X), there is kqueue, which also allows 
receiving notification of signals.  kqueue is particularly convenient 
because it allows signals to be monitored without disrupting their usual 
handling (and multiple queues can receive notification of the same 
signal even).  Unfortunately, there doesn't seem to be any analogue on 
Linux that allows multiple independent notifications of a signal, even 
with signalfd.

The problem with using any of these facilities is that it would increase 
the complexity of the overall code because there would be additional 
special cases.

>
>> There is, of course, the general problem that setting a signal handler
>> involves changing the global program state, and so it needs to be
>> coordinated to some extent with the rest of the program. At the low
>
> Exactly! As there also can be only one signal handler while you can have
> multiple Boost.Asio I/O service objects and I/O objects it gets even
> more complicated. As we felt it's more difficult to use libraries from
> different sources in one application when they all depend on SIGCHLD we
> went with wait(). You still need to coordinate. But this is something
> which we hope is easier to handle than libraries which steal signal
> handlers from each other.

I agree that using a separate thread reduces the need to coordinate with 
other code, but it seems that having one additional thread per process 
that is launched is an unreasonably high cost.

I don't really know what the best solution is.