AnyEvent and piped open

[Laurent]

On Fri, Jul 15, 2011 at 7:59 PM, Marc Lehmann <schmorp at schmorp.de> wrote:
> On Fri, Jul 15, 2011 at 06:42:40PM -0400, Laurent <laurent.aml at gmail.com> wrote:
>> > Neither wait nor waitpid changes function, actually.
>>
>> I meant, you cannot rely upon waitpid to reap your children, as there
>> is a chance they already got reaped by EV.
>
> Sure you can, it's absolutely deterministic. As long as you don't let EV
> reap the children, you can still do it yourself. This is, for example, why
> popen/pclose etc. in library functions isn't affected.
>
>> > This is not, of course, a limitation - as soon as the process no longer
>> > exists, it simply makes no sense to add a child watcher for it, because the
>> > very pid that identifies the process could have been reused.
>>
>> Of course... I assume the child still exist, as a zombie, as long as
>> it has not been reaped.
>> I think EV reaps all zombie children any time the event loop runs,
>
> Yes, thats what the event loop is supposed to do.
>
>> Other event loops could have a different behavior, ie just reaping
>> children they have an child watcher on.
>
> I disagree - you are using the word "just" far too lightly. With EV, it's an
> option, but if you use it, then you indeed need to use it for all the child
> processes that you run in an event-based way.
>
> The alternative you propose is polling for child process completion, which
> is not really an option for an event library.
>
>> In this case, unwatched zombies will live across event loop runs until
>> one reap them. In such oa case, the "limitation" would not exist (and my
>> testcase would work).
>
> The limitation is only a limitation if you want to rely on non-event-based
> methods (such as polling). EV allows you to do that, unless you mix
> event-based reaping and non-event-based reaping isn't doable (on POSIX).
>
> So, again, this really isn't a limitation (not even a "limitation") in EV,
> but a logical consequence of using events. Note that traditional use of
> popen/pclose works just fine even when EV reaps children.

That's because you consider that an event loop should not do pooling,
but it can.
In this particular case, pooling could even happen on SIGCHLD events,
to make it more event-friendly.

On a higher ground, I see no logic in the fact that an event loop
reaps children it has no business with.
What I see is a trade off implied by the existing OS mechanics and a
seek for performance.

Anyway, I am certainly not saying that a pooling approach would be
better that the EV one, and I am completely fine with the way EV
works.
I think it was worth making a point that all this is not that obvious.
Still, the EV doc mentions that one has to set child callbacks before
calling the even loop, while AnyEvent doc does not and let the door
open to issues like this one (esp. if this applies to other event
loops, as it seems it does). "AnyEvent's pure perl event loop handles
all cases correctly regardless of when you start the watcher." is
particularly misleading.

Thanks again for your work and your time.

-- Laurent