apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Norris <...@cataclysm.cx>
Subject Re: RESEND: Deficiencies in the poll and/or socket APIs
Date Tue, 24 Feb 2004 23:28:00 GMT
On Tue, Feb 24, 2004 at 09:39:01AM -0500, Bill Stoddard wrote:
> Greg Ames and I are working on an Apache 2.0 patch to do keep-alive reads 
> in an event-loop (to free up threads blocked on keep-alive connections). I 
> expect we will run into some of what you are now observing and dig into the 
> code and learn it in detail.

I've already done some digging into the poll code, and it seems pretty
straightforward. Let me know if you'd like to work together on that
piece so we can make sure that there's enough pieces in place to support
both Apache and a more traditional persistent-connection server.

> > pollset_remove() could be optimised if an index into the pollfd
> > array was held in apr_pollfd_t (or something similar, as this is
> > platform-dependent). We'd lose the ability to store a single
> > descriptor in a pollset twice, 
> I am not sure the ability to store a single descriptor twice is an
> issue. A pollfd array would need to be dynamically sizeable. We would
> not want to place artificial limits on the number of fs's in the
> pollset (unlike the array passed in to select() for example).

Absolutely, we don't want to place limits on the pollset if not
necessary. My point was that if we maintained a pointer to a
descriptors' location in the set, then we can't have the same descriptor
in the set more than once (unless we keep track of all of them, but I
can't see why you'd actually want the same descriptor in the set more
than once anyway).

> > 2. I need to be able to figure out when a socket has been closed by
> > the peer. The usual way to do this is to check how many bytes are
> > waiting to be read when the socket goes readable. I've used both the
> > FIONREAD ioctl and the MSG_PEEK flag to recv before to do this. It
> > doesn't seem that the APR socket API supports any mechanism like
> > this.
> I think that is correct. The biggest user of APR (Apache 2.0) just
> does a read when the socket goes readable. Either the read works and
> there are bytes to handle, or it fails because the client close'd its
> end of the connection.

It seems to me (as long as non-UNIX platforms have a mechanism to
support it) that it would be dead simple to provide a function that does
a FIONREAD and returns the number. Apache wouldn't even have to bother
with it.

> > Getting a POLLHUP event from the poll call also seems to work in
> > some places, but its not really portable[1], and APR does it
> > differently again.
> I agree this is not portable.

Is anyone aware of another commonly-used method to detect a closed

Anyway, this is enough confirmation for me that I'm on the right track.
I'll try to get a patch for the functionallity I need together soon, and
will submit it here.


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

View raw message