sysread() on a socket will read whatever data is available, then return; except when there is no data available, in which case it will hang until some data is available. You can avoid this by only calling sysread() when select() tells you there's data. <> will keep reading until it gets a whole line, which means that your IRC script will occasionally hang when it gets part of a line in one packet, causing select() to tell you there's data, but the next packet doesn't show up for a while.
I'm not sure how <>'s buffering will interact with select(). I think it's possible for select() to say no data is available, but <> to have data waiting in a read buffer, but because <> has the other problem described above (when used with select()) I haven't used it enough to find out for sure. If this putative problem exists, it will manifest as your program receiving some lines of input long after they were sent.