On Wed, Jan 16, 2008 at 04:17:10AM +0100, Marc Lehmann wrote:
> On Tue, Jan 15, 2008 at 10:47:33AM -0500, Chris Shoemaker <[EMAIL PROTECTED]>
> wrote:
> > > handler before creating the process, or before the process exits, only
> > > before you poll for more events.
> >
> > I'm glad we finally agree, in practice at least.
>
> No, we don't. Your claim was wrong and is wrong. We do not agree the
> least. I don't understand why you cannot accept that.
>From my perspective, you're agreeing with me. If you disagree, we'll
just have to agree to disagree about whether or not we agree!
> > In my opinion, this is a rather special and uninteresting exception to
> > the general rule that running the default event loop will eagerly reap
> > the exit status of children, even before an ev_child has started.
>
> Despite your opinion, it is by far the most common and important
> case. Your case, on the other hand, is very uncommon, and pessimising that
> a bit in favor of providing good and simple support for the common case
> makes sense (simple things should be simple, complex ones possible).
Ok, I'll take your word for it.
> > > libev doesn't make it as if a child died more than once, even if there are
> > > multiple ev_child watchers. this isn't possible with the unix semantics.
>>
>> Eh?! Sometimes I wonder if we're reading the same code. Of course it does!
>> Two watchers for the same pid. How many get triggered?
>
> Both.
>
>> TWO! It had better be so, because that's exactly what the code does:
>
> Indeed.
>
> > It loops over ev_childs, feeding all the events. Remember?:
>
> I know my code well, thank you very much. Please stop insulting me.
>
> > why I warned you that my patch changed that.) Understand, I'm not
> > criticizing the design, different apps have different goals. Again, I
> > really have to stick to POSIX semantics, so a child only dies once.
>
> The child dies only once, and this is reported properly by libev to all
> interested watchers. In no way does libev make it as if a child died more
> than once.
I'll assume that in your view this is somehow not equivocation.
There's no need for you to explain any further.
> > > in fact, your algorithm contains a race condition where an ev_child
> > > watcher gets the exist status of the wrong process (one that is started
> > > between the two waitpid calls), something libev avoids.
> >
> > I assume you're talking about:
> >
> > pid = waitpid (w->pid, &status, WNOHANG | WUNTRACED | WCONTINUED);
> > /* What if a new process is started right now? */
> > if (WCONTINUED && pid < 0 && errno == EINVAL) {
> > pid = waitpid (w->pid, &status, WNOHANG | WUNTRACED);
> > }
> >
> > I don't understand what you mean about the sending the status of the
> > wrong process. If the watcher gets an event, I think it's always for
> > a "matching" process. (It might match the process group, btw.)
>
> a) if you have a watcher that waits for pid 5, and one that waits for -1,
> only one of them gets the event, when both should.
right.
> b) if you have a watcher that waits for pid -1 and later start one for pid 5
> but the process was altready reaped, you lost the event.
not "lost" really, just delivered to the pid -1 watcher.
> c) if you have two watchers that wait for pid 5, then the second one might
> not get the exit status at all, or the exit status of the wrong one.
actually, one would get the exit status, and one would get ECHILD.
> there are other problems and races.
I don't see those as problems. That's the behavior I want.
-chris
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
