On Mon, 21 Jan 2002 13:48:55 -0500 Rocco Caputo wrote: +------------------ | On Mon, Jan 21, 2002 at 10:57:20AM -0700, Chris Fedde wrote: | > The following code gives me two identical read errors. Is there a way to | > tell which is associated with the close of the stdout file handle? | | [code] | | Not yet, but only because an interface for it hasn't been hashed out. | Would it be better to receive two error events or just one after both | handles closed? | | If two error events, I can add a new argument (ARG4?) with a copy of | the file handle. The code to deal with both handles is left as an | exercise for others. | | If one error event, then the wheel can take care of waiting for the | process to fully close. On the other hand, code that uses Wheel::Run | will have less control over how the child program cleans up. +------------------
I've fantasized about two interfaces. First would be to put the string 'STDIN' or 'STDERR' (or descriptors 1 or 2) in ARGV4 and assume the user knows that '$_[ARGV1] eq 'read' and $_[ARGV3]==0' is an EOF on a non blocking file handle. Another would be to have the Wheel do the work and introduce two new events: StdinEOF and StderrEOF. But this seems more like something in the component layer than the wheel layer. I notice that changes in 0.18 ensure that the error event does not arrive till all the data before the error has arrived? thanks chris --
