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 ...
my $coderef = sub {
my( $request ) = $_[0];
my $sent_header = 0;
my $agent = LWP::UserAgent->new( timeout => 45 );
my $response = $agent->request($request, sub { &data(\$sent_header, @_) },
2048);
.... deal with possible responses ...
sleep 2;
}
Later...
sub _start {
.... lots of tests on things ...
.... decided I need to run Wheel::Run ....
$self->{run} = POE::Wheel::Run->new(
Program => sub { $coderef->( $self->{request} ) },
StdoutEvent => 'stdout',
StderrEvent => 'stderr',
Filter => POE::Filter::Stream->new()
);
Where would I be calling delay? It seems to me I'd need to replace my sleep
call with it, but that coderef knows nothing of POE and it's running in a
child process. Should I be passing off KERNEL to $coderef->( ) and calling
delay from within the coderef?
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.
How do I know how long of a delay to use? Is using STDERR to signal
completion to the parent also bad karma?
Thanks.
> torvald
