apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Stoddard <b...@wstoddard.com>
Subject Re: RESEND: Deficiencies in the poll and/or socket APIs
Date Tue, 24 Feb 2004 14:39:01 GMT
Robert Norris wrote:

> [ Resending, as there's been no discussion, and I'm afraid it may have
> been missed. I need an answer soon. Thanks :) ]

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.

My comments that follow are just a little more reliable than speculation... (and if someone
wants to step in 
with definitive answers, please do so...).

> 
> I'm considering moving my application to APR over my own internal
> utility library (APR is much nicer), so I've started implementing a
> simple descriptor event loop to get a feel for it. However, I've run up
> against a couple of deficiencies in the API and I'm not sure where to go
> from here.
> 
> I'm working with APR 0.9.4. I'm only working off the headers to know
> what's possible, so if there's an obvious piece of documentation
> somewhere that I've missed, please just point me there.
> 
> 
> 1. I don't see a way to update the requested events for a fd that is
> already in a pollset. I can update pollfd->reqevents, but those changes
> never make it to the underlying pollfd structure (Unix).
> 
> It seems the only way to do this is to call pollset_remove(), then
> pollset_add() again. This is obviously suboptimal, as pollset_remove()
> does a search.

I think your observation is correct on both counts. The pollset API is basically a first cut
implementation 
and I would expect optimizations like you describe would not be in the implementation.

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

> but it would get rid of the search, which would make
> the addition of a new function to update the underlying pollfd trivial
> (no search required).
> 
> 
> 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.
> 
> 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.


Bill

Mime
View raw message