On Wed, 2002-06-26 at 11:08, Rocco Caputo wrote:
> The paradigm has recently shifted regarding POE::Wheel::Run.  Its new
> CloseEvent should now be a reliable and convenient way to tell when a
> child has gone away.

So far I have been conservative by checking both CloseEvent and the
arrival of SIGCHLD (mainly for the exit status).  

I have two concerns:

1. Event sequence.

It's not clear to me whether it's possible for SIGCHLD to arrive after
CloseEvent.

2. Exit status.

In many cases, CloseEvent alone is insufficient.  It only tells one that
the child process has no more output, but one does not know whether the
child has exited abnormally.  For example, it's possible that the child
process was killed, in which case, one would need to know that the
output might be incomplete.

I separate theses exits into five categories: success, failure, error,
timeout, and abort.

success - exit code 0, no signal, no coredump.
failure - non-zero exit code, may have a signal, or a coredump.
error   - the child process never started, check ErrorEvent.
timeout - child killed by the system, because it timed out.
abort   - child killed by the system based on a user request.

To make my life easier, since one of my application makes use of
POE::Wheel::Run extensively, I wrote a module to encapsulate these
states.

At one point I was also concerned whether there would be a problem
deleting a wheel before its child process is reaped by waitpid.  Based
on a quick look in POE::Kernel::_invoke_state, it looks as if the child
process will be reaped regardless of whether the wheel still exists.

Pete


Reply via email to