On Fri, Dec 07, 2001 at 01:21:54AM -0500, Jason Boxman wrote: > On Friday 07 December 2001 12:56 am, you wrote: > > On Thu, Dec 06, 2001 at 05:20:05PM -0500, Jason Boxman wrote: > > > On Thursday 06 December 2001 04:02 pm, you wrote: > > > > How should I detect EOF on the stdout from POE::Wheel::Run? > > > > > > > > SIGCHLD seems to come well before the last StdoutEvent, buffering > > > > I expect. I also see two ErrorEvents (ARG0='read', ARG1=0). One > > > > soon after the SIGCHLD and another after the last StdoutEvent. > > > > > > Yeah, I get something like that with my POE::Wheel. Sometimes I don't > > > get all the data from the STDOUT pipe before it finishes up and goes > > > away. I actually resorted to using a sleep 2; call in my Wheel's > > > executed coderef, but that's surely a kludge. > > > > This should be fixed in 0.17 or later, although it may not be if > > you're deleting the Wheel::Run instance before the pipes can be > > flushed. It would be best to have Wheel::Run track the pipes' status > > and emitting a "hey, close me" event when it's done. > > 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 ... torvald
