Deficiencies in the poll and/or socket APIs

[Robert Norris <ro...@cataclysm.cx>]

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.

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

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.

It would be easy to add a call to the socket API to get the number of
bytes waiting, but there may not be equivalent functions available on
non-Unix platforms.


So, where do people suggest I go from here? I'm happy to implement
any/all of this, and submit patches, I just want to make sure I'm going
down the right path before I start. Please let me know what the best
course of action is here.

Regards,
Rob.

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

Re: Deficiencies in the poll and/or socket APIs

[Marco Spinetti <m....@pisa.iol.it>]

Very interesting question.

I'd like to know the answer too.

+1.


--Marco


Robert Norris wrote:

>>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.
>>    
>>
>
>Bah, forgot the reference. Sorry.
>
>[1] http://www.greenend.org.uk/rjk/2001/06/poll.html
>
>  
>

Re: Deficiencies in the poll and/or socket APIs

[Robert Norris <ro...@cataclysm.cx>]

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

Bah, forgot the reference. Sorry.

[1] http://www.greenend.org.uk/rjk/2001/06/poll.html

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