On Thu, May 23, 2002 at 10:39:46AM -0400, Peter Chen wrote: > On Thu, 2002-05-23 at 09:29, Rocco Caputo wrote: > > On Mon, Jan 21, 2002 at 02:28:50PM -0700, Chris Fedde wrote: > > > > > > 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. > > > > Committed today, using STDIN, STDOUT, and STDERR instead of the file > > descriptor numbers. > > If I understand correctly, together with CloseEvent, this presents a > complete solution. Let me see if I fully grasp this. > > Here is one possible sequence of events: > > Event ARG0 ARG1 ARG3 > -------- ---- ---- ------ > ErrorEvent read 0 STDERR > sigchild CHLD $pid > ErrorEvent read 0 STDOUT > ErrorEvent read 0 STDIN > CloseEvent > > Now it's possible to detect EOF of an individual file handle. It's also > possible to know when all file handles are closed without counting them. > > Is this conclusion accurate?
It is slightly inaccurate. CloseEvent indicates when the child process has closed its STDOUT and STDERR handles. STDIN may still be available for input. I'm not sure if we can reliably tell whether STDIN has closed without writing to it. A more likely scenario: Event ARG0 ARG1 ARG3 -------- ----- ---- ------ ErrorEvent read 0 STDERR sigchild CHLD $pid ErrorEvent read 0 STDOUT CloseEvent Here you would probably delete the Wheel::Run instance and never see an ErrorEvent for STDIN. If you do, it's more likely to be a "Broken pipe": ErrorEvent write 32 STDIN The sense of the errors is backwards. It's a write error for STDIN and read errors for STDOUT and STDERR. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
