proposal: defer installing SIGCHLD

[Denis Bilenko]

On Thu, May 24, 2012 at 6:25 AM, Marc Lehmann <schmorp at schmorp.de> wrote:
> The real reason why it breaks existing apps is another one though: the
> behavious is deterministic right now - when you want to do your own signal
> handling, you e.g. block/ev_default_loop/restore/unblock, and that is much
> harder (if possible at all) to do otherwise.

It's not much harder if you really want to do it that way. Just start
a dummy child watcher after initializing the loop - that will trigger
the signal handler installation. However, you should not need to do
it. Instead, just don't use child watchers.

My point is that the mere presence of "ev_child_start()" call in your
code declares the intent of using libev's child reaping over any
other. If you don't have ev_child_start() in your code, then libev
won't install a signal handler so there's no need for specific order
of init calls or for undoing SIGCHLD installation.

I cannot imagine a case where someone would disable libev's child
reaping and then proceeds to use child watchers. Can any one give me a
non-hypothetical example of this? I know you can feed events to a
watcher, but if you're only feeding events to a watcher, you no longer
care which type of watcher it is, so use any other than child.

> the other library needs to reap children for libev
> as well (for example, by reaping all children and using ev_feed_event). Right
> now, you have to know what you are doing with libev, but that's unavoidable.

> If this was some important case, one could add an ev_feed_child_event to
> libev at little extra cost, so the other libraries doesn't need to take care
> of libev child watchers.

I agree that this case is not important and I think it's not worth
designing for.

Here's a more important case: the libev's libevent emulation.

Currently, it reaps children, which makes it incompatible with
libevent programs that have their own child management. With the patch
it all works out naturally - the libevent-only program will never call
ev_child_start, so libev never messes with signal handlers. On the
hand, the program that uses both libev's child watchers and libevent
API will work properly too.

I guess you can fix it following your own advice: make event_init() do
block/ev_default_loop/restore/unblock dance. Then libevent-only
program would work. For libev+libevent program, remember to call
ev_default_loop() before ev_init() and you're good.

However, if you defer signal installation it just works - no
workarounds necessary.

The new loop option would not help me unless there is also a function
to start child reaping at any time.