On 5/23/12, Marc Lehmann <[email protected]> wrote: > On Tue, May 22, 2012 at 01:21:35PM +0400, Denis Bilenko > <[email protected]> wrote: >> The patch below defers installing SIGCHLD until the first child >> watcher is started. Thus, if an application does not use child >> watchers, libev never installs a SIGCHLD handler. > > 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? > 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? 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.) >> Of course, using both the old way and the new way in the same app >> still won't work, but that's a reasonable limitation. > > 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. Ambrus _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
