On 09/11/2010 10:12 AM, Boris Schaeling wrote:
On Sat, 11 Sep 2010 00:02:38 +0200, Jeremy Maitin-Shepard <jeremy@jeremyms.com> 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.