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 05:48:52 GMT

On Mar 4, 2004, at 9:17 PM, Robert Norris wrote:

> On Thu, Mar 04, 2004 at 07:39:48PM -0600, Scott Lamb wrote:
>> On Mar 4, 2004, at 6:44 PM, Robert Norris wrote:
>>> 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().
>
> Interesting. I've never actually seen select() and friends do this, but
> of course there's lots of broken OSes out there.

Well, they don't even consider it to be broken. I've found the message  
in question:

<http://groups.google.com/groups?q=select+hint+group: 
linux.kernel&hl=en&lr=lang_en&ie=UTF-8&oe=UTF 
-8&group=linux.kernel&c2coff=1&safe=off&selm=20030609031009%2414ba%40gat 
ed-at.bofh.it&rnum=1>

>
> I'm not familiar with a read on a closed socket returning anything  
> other
> than 0. It doesn't make sense to me that it would return -1/EWOULDBLOCK
> - if its closed, then a read should never block - it should just return
> 0.

I've never seen that, either.

>
> If select() reports that a socket is readable when its not, then I
> suppose FIONREAD _might_ return 0 (I honestly don't know),

I would expect it would be similar to what happens if no select() has  
been made and nothing is available. Doesn't it return 0 then?

>  but I would
> still expect recv(MSG_PEEK) to return -1/EWOULDBLOCK (sinces it still
> does a read). So surely that would be a safe way to determine if  
> there's
> anything in the buffer?

Ahh. I'd forgotten about recv(..., MSG_PEEK). That might work.

> I want a basic I/O event layer that tells the application
> above it when something interesting happens on a socket (ie something  
> to
> read, ready to write, closed). If the event layer has to read data to
> find this out, then this abstraction doesn't work.

Is distinguishing close really that important? What select() tells you  
is that you can probably do a read() or write() without getting  
-1/EWOULDBLOCK. Both of those are true when the socket is closed. I  
guess I just don't understand the importance of making finer  
distinctions than that before you actually try to do something.

Scott


Mime
View raw message