proposal: defer installing SIGCHLD
Zsbán Ambrus
ambrus at math.bme.hu
Wed May 23 23:09:26 CEST 2012
On 5/23/12, Marc Lehmann <schmorp at schmorp.de> wrote:
> On Tue, May 22, 2012 at 01:21:35PM +0400, Denis Bilenko
> <denis.bilenko at gmail.com> 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
More information about the libev
mailing list