Okay, I know there are 3 obvious reasons IO::Select::can_read returns:

1) a filehandle has data to be read
2) a filehandle has been closed
3) timeout

The problem is, I'm running into cases where can_read returns, but none of the above is true. Unfortunately, it's a big, bloated bunch of libraries and scripts to make it run, and I haven't been able to condense it into a simple testcase that others can use to reproduce it. But I can show you the code:

        # instead of simply reading on the socket filehandle, we'll
        # use IO::Select here to give us timeout capabilities.  
        # add the socket to our IO::Select object.
        #
        my $sel = new IO::Select ($sock); # $sock is a IO::Socket obj
        
        # now wait until our IO::Select obj tells us that one of its 
        # sockets (and we only added one) is ready to be read (or 
        # times out).
        #
        if (my @socks = $sel->can_read($timeout)) {
            $sock = shift(@socks);
            # ...read socket data, or print warning if the 
            # socket was closed remotely...
        } else {
            croak sprintf("Timed out, socket connection status: %d\n",
                              defined($sock->connected()));
        }
[download]

In most cases this works fine, with a $timeout value of say 300. Occasionally, however, I'll instantly fall through to the else clause, clearly not having waited for $timeout seconds. If I set $timeout to undef it works. I am certain that the message I'm attempting to read is being sent in all cases, why is it that if I have a $timeout value I get this odd behavior? Are there known reasons that can_read would return undef before the $timeout seconds have elapsed?

Thanks.

20050203 Edit by castaway: Changed title from 'What makes can_read return?'