apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Norris <...@cataclysm.cx>
Subject Re: PATCH: Determine how many bytes are waiting to be read from a socket
Date Fri, 05 Mar 2004 03:17:21 GMT
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.

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

If select() reports that a socket is readable when its not, then I
suppose FIONREAD _might_ return 0 (I honestly don't know), 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?

(I hope there is some relatively portable way - if not then there's
probably a lot of I/O multiplexing servers out there that are could be
doing the wrong thing).

> >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.

Not really. 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.

But thats specific to my app anyway. The real thing we have to work out
is if there is a reliable way to determine how much data is waiting to
be read (regardless of whether we're blocking or not, or if select() is
being used). It seems at the very least, recv(MSG_PEEK) should do this.


Robert Norris                                       GPG: 1024D/FC18E6C2
Email+Jabber: rob@cataclysm.cx                Web: http://cataclysm.cx/

View raw message