Disabling the SIGCHLD handler

Marc Lehmann schmorp at schmorp.de
Sun Jan 13 06:55:58 CET 2008

On Sat, Jan 12, 2008 at 11:51:04AM -0500, Chris Shoemaker <c.shoemaker at cox.net> wrote:
> Actually, ev_child is not usable by rubinius because it eagerly consumes
> all child exit statuses, even before an ev_child has been started.

That is untrue. It only does that when the default event loop is running,
when you are in a watcher or outside any ev_loop call libev will do no
such thing.

> 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.

An event-based app doesn't block and poll for the exist status of
processes, it registers handlers for them.

> 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.

As I explained, if for whatever reason it is inconvinient to use it,
don't. Libev doesn't force the use of its child watcher.

> > 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.

But ev_signal has the same problem: As soon as some part of a program
registers a watcher, signal handlers instaleld via sigaction stop working.

> > 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?

That would mean a crash. I don't think that this is acceptable, as one of
the basic premises of the default loop is to support all those features.

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

Other factors would, too, as signal handlers are unsharable, just like
waiting for child exist statuses is unsharable. You'd only postpone the

> 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.

How does it do so? Looping over all pid's on all calls to sigchld? Thats
extremely inefficient...

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

What is "unreliable signal delivery"? libev doesn't do anything to signals
after a fork, so whatever you see is probably normal (POSIX) behaviour or
some bug.

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

None that I am aware of. Libev itself doesn't support "unreliable signals"
(if that is the same as "unreliable signal delivery"), and it doesn'T
touch signal handlers once installed.

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

More information about the libev mailing list