Re: POE::Wheel::Run EOF again
On Wed, 2002-05-22 at 18:41, Rocco Caputo wrote: Do you specifically need to know when STDOUT is closed, or is it more important to know that the child is done sending information at all? The later would be sufficient, even though it would be nice to have finer grain control. For example, I am reading the STDOUT of /bin/rpm -qa. What I need to know is when to emit an event to tally the output received. In this instance, I do not care about STDERR. However, I can imagine some applications that do. If it's the latter, I have just committed a new version of Wheel::Run that includes a CloseEvent. The CloseEvent will be fired when the child process has closed its last output filehandle. I understand. I suspect in many applications, this is sufficient. It's much cleaner than counting the number of read errors. Thank you. Pete
Re: POE::Wheel::Run EOF again
On Wed, 2002-05-22 at 00:33, Chris Fedde wrote: I saw behavior like this with 0.18 on FreeBSD 4.5 and Solaris 2.8. After 0.19 the sigchld consistently arrives after two error events marking failed nonblocking read on stderr and stdout. Unfortunately, I don't share the same experience. I observe the following sequence read error with error number 0 sigchild 2nd read error with error number 0 Apparently, the first read error comes from STDERR, and the second one is STDOUT. My current kludge is to count the number of read errors. When two of them are received, one can be assured that both STDERR and STDOUT are flushed. This approach was suggested on the mailing list last December as well. To my knowledge there is still no way to map the error events back to file handles. Let me make sure I understand this. Do you mean there is no way to know which file handle caused the read error? Pete
Re: POE::Wheel::Run EOF again
On 22 May 2002 17:49:15 -0400 Peter Chen wrote: +-- | On Wed, 2002-05-22 at 00:33, Chris Fedde wrote: | To my knowledge | there is still no way to map the error events back to file handles. | | Let me make sure I understand this. Do you mean there is no way to know | which file handle caused the read error? +-- Yes that's what I mean. I have found no way to discover which file caused which error. That means that using a sentinal in the stdout stream or close counting is necessary. --
Re: POE::Wheel::Run EOF again
On Tue, May 21, 2002 at 06:44:18PM -0400, Peter Chen wrote: Back in last December, there was a thread on how to handle EOF on the stdout from POE::Wheel::Run. Was there any follow up to this? http:[EMAIL PROTECTED]/msg00767.html I am seeing the same problem in POE 0.19. Is there a way to find out that STDOUT has closed? Do you specifically need to know when STDOUT is closed, or is it more important to know that the child is done sending information at all? If it's the latter, I have just committed a new version of Wheel::Run that includes a CloseEvent. The CloseEvent will be fired when the child process has closed its last output filehandle. That doesn't mean the child process has gone away, though. It may still have its STDIN open. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
Re: POE::Wheel::Run EOF again
On 21 May 2002 18:44:18 -0400 Peter Chen wrote:
+--
| Back in last December, there was a thread on how to handle EOF on the
| stdout from POE::Wheel::Run. Was there any follow up to this?
|
| http:[EMAIL PROTECTED]/msg00767.html
|
| I am seeing the same problem in POE 0.19.
|
| Is there a way to find out that STDOUT has closed?
|
| Pete
+--
I have not had time to clean it up yet. But my test code now behaves
predictably: All the output arrives before sigchld. I can't tell
which file handles the errors are on. But all the data has been read
before the sigchld which was the big deal for me.
use POE qw(Filter::Line Wheel::Run);
use Time::HiRes 'time';
use strict;
use warnings;
sub _start {
my $heap = $_[HEAP];
$heap-{wheel} = POE::Wheel::Run-new(
Program = [qw( /usr/bin/find . -type f)],
ErrorEvent = 'error',
StdinEvent = 'stdin',
StdoutEvent = 'stdout',
StderrEvent = 'stderr',
Filter = POE::Filter::Line-new(),
);
$_[KERNEL]-sig('CHLD', 'child');
}
sub output {
print join(':', time(), 'got',
grep({defined} @_[STATE, ARG0, ARG1, ARG2, ARG3, ARG4])), \n;
}
POE::Session-create(
inline_states = {
_start = \_start,
error= \output,
stdin= \output,
stdout = \output,
stderr = \output,
child= \output,
}
);
$poe_kernel-run();
exit 0;
--
Chris Fedde
Re: POE::Wheel::Run EOF again
On Tue, 2002-05-21 at 18:58, Chris Fedde wrote: I have not had time to clean it up yet. But my test code now behaves predictably: All the output arrives before sigchld. I can't tell which file handles the errors are on. But all the data has been read before the sigchld which was the big deal for me. Is this algorithmic, i.e., the code ensures that STDOUT is flushed before delivering sigchld? If it's not, how do we know this behavior is deterministic? I am wondering whether the observed behavior is system dependent. I am seeing a different behavior on my test system (PII-350, Mandrake 8.1, perl 5.6.1, POE 0.19). While doing a /bin/rpm -qa, which should return 804 lines, sigchld is consistently delievered before all 804 lines are received. The number of lines missing ranges widely up to 200+. We all care about having all the data read. However, counting on sigchld being delivered after STDOUT is flushed does not appear to be reliable. Pete
