in reply to Re^2: Malfunctioning select() call on a FIFO
in thread Malfunctioning select() call on a FIFO

a simple "$fifodata = <FIFO>;" has always worked here (though I'll admit sysread() is probably better).

Is is better simply because using buffered IO with select is wrong.

The only reason I even tried using sysread() instead was in case <FIFO> was somehow leaving something on the FIFO

Leaving stuff on the FIFO is fine. <FIFO> is bad because it can return less than what it reads from the FIFO. That causes select to block when it shouldn't. For example,

use IO::Select qw( ); use IO::Handle qw( ); pipe(my $rfh, my $wfh) or die; $wfh->autoflush(1); if (fork()) { my $sel = IO::Select->new($rfh); while ($sel->can_read()) { my $got = <$rfh>; last if !defined($got); chomp $got; print("It took ", (time()-$got), " seconds to get the msg\n"); } } else { for (;;) { print($wfh time(), "\n") or die; print($wfh time(), "\n") or die; sleep(3); } }
It took 0 seconds to get the msg It took 3 seconds to get the msg It took 0 seconds to get the msg It took 3 seconds to get the msg It took 0 seconds to get the msg ...

But with sysread:

my $sel = IO::Select->new($rfh); my $buf = ''; while ($sel->can_read()) { sysread($rfh, $buf, 64*1024, length($buf)) or last; while ($buf =~ s/^(.*)\n//) { my $got = $1; print("It took ", (time()-$got), " seconds to get the msg\ +n"); } }
It took 0 seconds to get the msg It took 0 seconds to get the msg It took 0 seconds to get the msg It took 0 seconds to get the msg It took 0 seconds to get the msg It took 0 seconds to get the msg ...

I point out again that this select() call used to work, and has not been changed since then;

And select is still working properly. The problem has nothing to do with select.

because every select() call on the FIFO after the first command is read from it is saying that there is data on the FIFO to read

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.

Replies are listed 'Best First'.
Re^4: Malfunctioning select() call on a FIFO
by Llew_Llaw_Gyffes (Scribe) on Jan 06, 2010 at 20:46 UTC

    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.

      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.

        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.