apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Lamb <sl...@slamb.org>
Subject Re: PATCH: Determine how many bytes are waiting to be read from a socket
Date Fri, 05 Mar 2004 01:39:48 GMT

On Mar 4, 2004, at 6:44 PM, Robert Norris wrote:

> On Thu, Mar 04, 2004 at 06:04:05PM -0600, Scott Lamb wrote:
>> On Mar 4, 2004, at 4:51 PM, Robert Norris wrote:
>>> I use this to determine if the peer has closed the connection. In 
>>> that
>>> case, the socket goes readable, and this function reports 0 bytes
>>> waiting.
>>
>> I don't think this is correct. select() and similar functions can
>> return spuriously, at least on some platforms[*]. I would imagine this
>> would return 0 in such a case, and the socket would not have closed.
>> Why not just do the read and see if it returns 0?
>
> The connection is only closed if the socket is readable and there's no
> bytes waiting. The results of select()/poll() are undefined unless they
> return successfully.

I'm saying that I believe select(), poll(), etc. can return 
successfully with an indication that a socket is available for read() 
or write() when in fact it is not. In addition to the page I mentioned, 
there was a discussion about this on linux-kernel a while ago, I 
believe. They said (from memory) that (a) you should always use 
non-blocking IO with select and (b) you should not be surprised if a 
read() or write() returns -1/EWOULDBLOCK, even immediately after a 
select() that indicates readability/writability for that descriptor. In 
this situation, I believe a call to return the number of waiting bytes 
would return 0; there'd be no way to distinguish the EOF from the 
spurious return until you actually do the read().

> Just doing the read is no good - I'm writing an event notifier and I
> only want to actually read the data if there is data waiting (otherwise
> my abstraction breaks).

Then I believe your abstraction is broken.

Scott


Mime
View raw message