Disabling the SIGCHLD handler

Chris Shoemaker c.shoemaker at cox.net
Sat Jan 12 17:51:04 CET 2008


[Sorry for the poor formatting, I'm responding to an email that I
didn't receive.]

> On Wed, Jan 09, 2008 at 08:36:32PM -0700, Tony Arcieri <tony at clickcaster.com> wrote:
> > But, rather than using ev_child, we have our own (legacy) SIGCHLD handler
> > which does all sorts of fantastic legacy stuff and doesn't exactly map onto
> > ev_child very well...
> 
> Or maybe it maps fine, but you can't change it? :)

Actually, ev_child is not usable by rubinius because it eagerly consumes
all child exit statuses, even before an ev_child has been started.

You could argue that it's the application's responsibility to catch
every ev_child event and store the exit status indefinitely just in
case it might need it in the future.  However, this is very
complicated and requires complex locking between the reader and writer
(the ev_child handler) of the data store for eagerly-consumed exit
statuses.

> > It'd be super handy if there were a way to use libev's default loop to
> > receive signals, sans the built-in SIGCHLD handler.
> 
> I do not think so: the default loop is for use by all components in a
> program. If you need a loop without signal handling, just create one.

Actually, rubinius wants to use the default loop for ev_signal.

> You can also overwrite the signal handler in that "legacy" app with the
> other sigchld handler.
> 
> The problem with disabling is, what should libev do when asked to provide a
> child watcher? abort?

How about treating it exactly as if the loop didn't support ev_child,
just like every non-default loop?

> 
> > Would you consider adding an option to ev_default_loop() to allow for
> > this?
> 
> I am, if there is a better reason for it. I think the existing options
> already cover this nicely. If its demonstrably problematic, then I will
> add such an option, but I think an alternative loop is the corretc way to
> approach the problem (thats what they are there for).

Sure, a non-default loop would avoid the sigchld handler, but prevents
me from using ev_signal.  :(

> Note also that its quite valid to install your own handler and at the same
> time use ev_feed_signal_event to daisy-chain thre sigchld into libev, thus
> breaking nothing.
> 
> Or you can install your legacy sigchld handler as normal SIGCHLD watcher
> - multiple watchers per signal are allowed (ok, wouldn't make much sense,
> just override it :)

I would very much like to get rid of my sigchld handler, but it has an
important property that I need: it does not consume the exit status of
any processes unless it has been explicitly asked to.

On another note...  I'm having problems with unreliable signal
delivery after a fork - with poll, select and epoll backends.

I'll try to narrow it down, but are there any known bugs I should be
aware of?

Thanks,
-chris



More information about the libev mailing list