You're using sysread, right? When sysread return zero bytes read, it indicates EOF. For a fifo, that means the other end of the fifo was closed. The fifo is still closed every subsequent time you call select, so select keeps signaling that the handle needs to be serviced. Similarly, if sysread returns undef, it indicates an error occurred.

Update: Disambiguated pronouns and clarified what EOF means for a fifo.

I tried switching to a sysread(FIFO, ...) from using <FIFO> in the hopes that it might solve the problem, yes. It didn't make any difference, though. What's puzzling me is that this code USED to work, and now it doesn't, but the code hasn't been changed between when it worked and now.

One should not attempt to mix buffered I/O (like "read" or <FH>) with "select"

Most definitely. Data could be waiting in the buffer and select wouldn't know anything about it.

while (sysread(FIFO, $l, 255)) { $fifodata .= $l; }

Using while there defies the purpose of using select. If there's less than 256 bytes available, sysread will block the second time through the loop. You want:

my $rv = sysread(FIFO, $fifodata, 64*1024, length($fifodata));
[download]

(Big is good. It's not a problem if fewer bytes are available.)

The "ready for reading" half of your select loop should look something like:

my $rv = sysread(FIFO, $fifodata, 64*1024, length($fifodata));

if (!defined($rv)) {
    ... handle error ...
}

if (!$rv) {
    ... handle eof. There might be a partial message in $fifodata ...
}

while (...$fifodata contains a complete message...) {
    ...extract message from $fifodata...
    ...process message...
}
[download]

For fixed length records, the bottom loop might look like

while (length($fifodata) > $MSG_SIZE) {
    my $msg = substr($fifodata, 0, $MSG_SIZE, '');
    process_msg($msg);
}
[download]

For variable length records, s/// is convenient

while ($fifodata =~ s/^([^\n]*\n)//) {
    my $msg = $1;
    process_msg($msg);
}
[download]

The correction on the usage of sysread() is taken. However, I have to point out that this misses the point of the problem. My problem is not how to correctly read from the FIFO; a simple "$fifodata = <FIFO>;" has always worked here (though I'll admit sysread() is probably better). The problem is how to make the select() on the FIFO work properly again instead of always returning true, so that the handler sleeps until there's data available on the FIFO instead of going into a tight loop and repeatedly trying to read from the FIFO as fast as the CPU can execute the inner loop. The only reason I even tried using sysread() instead was in case <FIFO> was somehow leaving something on the FIFO that was making select() think new data had become available to read.

I point out again that this select() call used to work, and has not been changed since then; it's just ... stopped working. The "if (select(...)) {...}" call, on the FIFO, has become effectively an "if (1) {...}" after the first time the other end of the FIFO is written to.

Just to make sure the other end was being properly closed, I wrote this little test tool:

#!/usr/bin/perl
my $fifo = shift(@ARGV) || die "No FIFO";
if (-p $fifo)
{
    open(FIFO, ">$fifo") || die "Cannot open $fifo for writing";
    print FIFO "/.\n" || die "Cannot write to $fifo";
    close(FIFO) || die "Could not close $fifo";
}
else
{
    print "$p is not a FIFO.\n";
}
[download]

I start the client, it runs normally with negligible CPU utilization; I run the test script; it opens the FIFO, writes to it, closes the FIFO, and exits; the client executes the command sent through the FIFO; and client CPU utilization goes immediately to 100% and stays there, 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, even after the writeable end of the FIFO has been closed.

Thinking about it, it's been long enough since I last used this functionality of the client that it's entirely possible that it stopped working when I upgraded from Perl-5.8 to Perl-5.10, or possibly even when I upgraded from Perl-5.6 to Perl-5.8.

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);
    }
}
[download]

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
...
[download]

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");
        }
    }
[download]

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
...
[download]

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.

Instead of :
sysopen (FIFO, $icbmfifo, O_RDONLY|O_NONBLOCK);
We use:


sysopen (nullFile, $icbmfifo, O_RDONLY|O_NONBLOCK);<br/>
sysopen (writeFile, $icbmfifo, O_WRONLY|O_NONBLOCK);<br/>
sysopen (FIFO, $icbmfifo, O_RDONLY);<br/>
close(nullFile);
[download]



This makes the program wait for data on the FIFO.