in reply to multiple socket streams

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.

Replies are listed 'Best First'.
Re^2: multiple socket streams
by Forsaken (Friar) on Jun 08, 2004 at 08:28 UTC
    According to the docs, using buffered reading such as <> combined with select() is a recipe for disaster :-) I gave it a try with sysread() instead and that seems to work fine. As long as there is a timeout on select() to avoid falling into the same trap as before, it runs through each of the filehandles nicely, checks if there's any incoming data, and if so, reads it in.

    Great tip, tx.