[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 _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
