On Fri, Dec 07, 2001 at 11:17:14AM -0500, Jason Boxman wrote:
> On Friday 07 December 2001 07:02 am, you wrote:
> <snip>
> >
> > > I use STDERR to signal The Wheel::Run's job completion as I'm using
> > > STDOUT as a data stream channel. When I get a specific 'done' event from
> > > STDERR I kill the wheel. I guess it's possible the STDERR event is
> > > caught before the STDOUT pipe is flushed. The sleep 2; fixed this in
> > > most instances, but I still end up with lost data 5-10% of the time.
> >
> > Please do not do things like that. You cannot avoid races with delays, even
> > if they are really big. You should be happy instead, that you found it :)
> > Is this behaviour because input events now go through the queue, and
> > signals not ? Or did I miss something ...
[...]
> I don't know if this has to do with Input Events and the queue. I've always
> experienced this behavior with CVS. I haven't tested with earlier code.
Which is odd, because STDOUT and STDERR in the child process are made
unbuffered, and I explicitly close those filehandles before exiting.
$program->();
# In case flushing them wasn't good enough.
close STDOUT if defined fileno(STDOUT);
close STDERR if defined fileno(STDERR);
Can you put together a simple program that loses data? I'll merge it
into the Wheel::Run tests, and I'll know for sure when it's fixed.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
