Re^4: Malfunctioning select() call on a FIFO

No, it's saying that the handle needs to be serviced. Specifically, it needs to be closed because it reached EOF. I explained this. Stop using select on a handle you're told is closed.

Aaaah.... your meaning was not clear to me. So what you're telling me is that a FIFO, now, must be regarded as a one-shot that can be read to EOF once, then must be closed and re-opened in order to re-use it? One can no longer simply keep the read end open and wait for more input to be written to it by the same or a different "client"? (Doing so used to work. Is it then possibly a now-fixed bug in Perl's handling of FIFOs that it ever did work?)

I've now rewritten the code to read the FIFO (yes, using sysread), then immediately close and re-open it. I was concerned that this might introduce the possibility of race conditions, but testing shows that this is not in fact a problem. Thanks for the explanation of what was happening here; I just didn't actually "get" the key part of the explanation the first time around.

Comment on Re^4: Malfunctioning select() call on a FIFO

Replies are listed 'Best First'.
Re^5: Malfunctioning select() call on a FIFO by ikegami (Patriarch) on Jan 06, 2010 at 21:46 UTC
So what you're telling me is that a FIFO, now, must be regarded as a one-shot that can be read to EOF once I didn't say anything about named fifos specifically, so no. But it does seem to be the case. I don't know if there's anything special you can do with named fifos to reset them.	[reply]
Re^6: Malfunctioning select() call on a FIFO by Llew_Llaw_Gyffes (Scribe) on Jan 06, 2010 at 21:52 UTC
Well, until and unless I learn otherwise, I'm going to assume that (a) I was unknowingly misusing the FIFO from the start, and (b) the only reason I was getting away with it was because of a bug. Thanks for your patience.	[reply]