On Sun, Jan 13, 2008 at 06:05:18PM -0500, Chris Shoemaker <[EMAIL PROTECTED]>
wrote:
> > An event-based app doesn't block and poll for the exist status of
> > processes, it registers handlers for them.
>
> Right. I'm neither blocking nor polling. See below.
Ok.
> > 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.
>
> Well, it doesn't force the use of ev_child, but it does force an
> application to choose between either:
>
> a) not having access to the exit status of children that exited before a
> ev_child was started, OR
As I said earlier, this is untrue. Why do you kepe repeating it? libev
*explicitly* allows registering an ev_child handler after the child has
exited already, anythign else would be pointless indeed.
This is actually used in practise, so if it doesn't work, I'd like to know
why.
> b) not being able to use ev_signal
That is also untrue. Nothing precludes libev users form using ev_signal
but install their own sigchld handler, as was explained before.
> I'd like to use ev_signal (for unrelated purposes, mostly) AND have access
> to exit status of children that exited before I knew I would want their
> exit status, (for which I know I need to use my old SIGCHLD handler, that
> I used with libevent).
I will never understand how people can "know" factually wrong things.
You made this claim repeatedly, please back it up, or take it back. Thanks.
I certainly know a number of ways to implement that, and for the most
common case (creating a process, and then waiting for it to exit) its
trivial (as you can validly register the child handler after creating the
process).
> > 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.
>
> I don't follow. I don't intend to use sigaction. I want to use ev_signal
> for all signal watching.
I was told that ruby gives access to functions such as waitpid or
sigaction, for which the problem exists. If that is untrue, then I was
misinformed, sorry.
> > > 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.
>
> Well, I would think that aborting if the application attempted to use
> a feature that it explicitly disabled would be acceptable.
I don't, because "the applciation" is just one of the libev users, other
modules might use it as well. By disabling standard fucntionality this would
make it hard to integrate third-party software. That means one best avoids
crippling functionality but instead should use and improve it.
And even if, you cna always provid your own child reaper. I just do not
see your problem.
> another option could be to offer another loop type: Something just
> like the default loop but without the SIGCHLD handler.
No, signals are an unsharable resource just like sigchld. It just cannot
be done with posix, sorry.
> > 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 don't follow. What problem would I postpone?
As soon as somebody registers a child handler via e.g. sigaction - same
problem. I was told this were possible, but since it doesn't seem to be,
there wouldn't be a problem.
> > How does it do so? Looping over all pid's on all calls to sigchld? Thats
> > extremely inefficient...
>
> Instead, I loop over only list of outstanding calls to waitpid,
I assume you do this on every call to waitpid, too...
> As for efficiency, this makes the SIGCHLD handler O(N) in the number
> outstanding waitpid calls. I don't expect that to be a problem,
> but I'm open to suggestions for improvement.
The improvement would be to use an event-based model, not a polling model.
> [ After writing this, I took a look at how ev_childs are handled, and
> realized that it would be quite easy to modify libev to provide the
> behavior I want. I would just remove the waitpid(-1) call, and put a
> waitpid(pid) call inside the loop over childs[]. As an added benefit,
That would break it, however.
> semantics of waitpid(). I will very likely do exactly that, and I'll
You are free to do that, but I would still be happy to understand why you
feel the urge to patch libev when you can just provide your own sigchld
handler instead, as you originally wanted.
For some reason, you keep ignoring the obvious solution that ha sbeen
mentioned a few times already.
> send a patch if you're interested. ]
No, I am not interested in introducing bugs.
--
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
