proposal: defer installing SIGCHLD

[Marc Lehmann]

On Wed, May 23, 2012 at 11:09:26PM +0200, Zsbán Ambrus <ambrus at math.bme.hu> wrote:
> > That breaks existing applications, so, no.
> 
> The problem is what happens if you want to use a child watcher to wait
> on a child process that exits before you have started any child
> watcher, right?

That's the reason that some signal handler must be in place before
ev_child_start, or you need to call waitpid, yes.

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.

> > With the current behaviour you can indeed choose to either support libev or
> > a third-party way to handle this, and both can be used, but not mixed
> > - the last library initialised wins.
> 
> That's right, but wouldn't it be even easier to control this if there
> was also a flag you pass to ev_default_loop that asks the loop not to
> install a SIGCHLD signal handler at all?

Well, it would bloat libev's code for a very rare use case (and mixing
different event libraries always depends on both libraries). It's trivial
for the caller to do it right now.

> You can't always choose freely which library to initialize last.
> (Of course, you could always save the signal handler before libev
> initializes and restore it afterwards.)

Yes, it only requires cooperation from the party that uses libev, which is
unavoidable anyway.

> > Depends on the the other library - libev supports having sigchld managed
> > for it by another package.
> 
> Would you do that by installing the signal handler of the other
> library first, having that signal handler first reap using
> waitpid/wait4 only the few child processes that library owns, then
> calling the saved signal handler libev has installed?  That way, the
> other library wouldn't have to know anything about libev.

No, that would be racy - 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.

However, the unix design doesn't allow for multiple event libraries to
poll process-wide events, and doing that always needs cooperation between
interested parties, and this cooperation is not easy to achieve in a
generic way. One side has to give.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\