On Wed, 2002-06-26 at 13:05, Rocco Caputo wrote: > This is an excellent point. If you've come up with a better interface > for child processes, we can do some harsh revising. I'd really like > to see Wheel::Run redone as a component anyway. Then it can manage > its own signal handlers.
We do seem to be heading that way. I like it. In addition to what's available in the Wheel::Run interface, I may suggest the following for consideration: 1. StdoutCloseEvent 2. StderrCloseEvent. Both can be detected through ErrorEvent already. These are more convenient, and more explicit. 3. SigchldEvent, a more explicit interface for sigchld handler, which is of particular importance for this component. It will be nice to only receive this event for child processes generated by this component, and use the return value from the handler to decide whether the signal should be propagated. 4. CompleteEvent, receives same arguments as sigchld handler. Instead of the developers keeping track of whether both CloseEvent and SIGCHLD have been received, they can use CompleteEvent. 5. KillEvent, analogous to wheel->kill, takes a signal number or name as the argument. 6. Timeout, specifies the number of seconds to timeout, upon which TimeoutEvent is dispatched. Undef or 0 means there is no timeout. 7. TimeoutEvent. See above. These will cover most of the functionalities that I added in my WheelState module. There are a few convenience functions, that may be handy: 1. exit_status, returns the exit status of the child process. 2. exit_code, returns $exit_status >> 8 3. exit_signal, returns $exit_status & 127 4. exit_coredump, returns $exit_status & 128 All 4 return undef if the child process hasn't exited. I suspect some CPAN modules may have already defined this, but I haven't found one. Pete
