Re: select appears to ignore pending data on socket.

As has already been stated, use of the <> operator is a buffered operation. In the provided loop, you invoke the operator once. If there are 3 newlines within the received data, your program would have received up to the first, but the remaining data could well have been read off the socket by the buffering logic. The select would hang, because the socket is empty, but there is data in the buffer that you have not read.

I don't think that you have a choice about using non-blocking sockets. If you are receiving variable-length data, I can't recall a way to look at how much is in the socket buffer before reading. You can either read a char at a time, and keep checking via select (not very pretty), or switch to non-blocking.

You mention having switched to non-blocking mode. Did you do this using sysread/recv? Could we see the code that did not work in this instance?

Comment on Re: select appears to ignore pending data on socket.

Replies are listed 'Best First'.
Re^2: select appears to ignore pending data on socket. (var-len) by tye (Sage) on Nov 05, 2007 at 14:38 UTC
the <> operator is a buffered operation. If there are 3 newlines within the received data, your program would have received up to the first, but the remaining data could well have been read off the socket by the buffering logic. The select would hang, Precisely. Excellent point; a particular pitfall to `<$sock>` not clearly pointed out before. I don't think that you have a choice about using non-blocking sockets. If you are receiving variable-length data, I can't recall a way to look at how much is in the socket buffer before reading. You can either read a char at a time, and keep checking via select (not very pretty), or switch to non-blocking. Wrong. If you use sysread (or recv) with select then there is no problem reading variable-length data. If you don't read enough to drain the input already available, then select will tell you that there is more to be read. If you ask for more data than is available, then sysread will return only what is available to you without hanging. Of course, if you are hoping to process the input only as complete lines, then this adds a layer of complexity where you may have to buffer up partial lines read and only process them the next time select tells you that there is data to be read. However, the typical archecture for using select is to have an object for each socket which means that buffering up partial lines in this object is no big deal. - tye	[reply] [d/l]
Re^2: select appears to ignore pending data on socket. by Zidane (Acolyte) on Nov 07, 2007 at 17:51 UTC
well, what an informative reply. i had not considered the buffering logic reading before select checks again, but it does seem to simply explain the problem i am having, thankyou. unfortunately, i cannot provide working code atm, i am at work and this is a little home project, however, in short, i moved over to using io::event which apparently allows me to use <> to read the io::select object as though it were a file handle. thankyou, it would appear illuminatus has illuminated</P. me ;)	[reply]