On Sat, Jan 12, 2008 at 11:51:04AM -0500, Chris Shoemaker <[EMAIL PROTECTED]>
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
problem.
> 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
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
