apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Norris <...@cataclysm.cx>
Subject RESEND: Deficiencies in the poll and/or socket APIs
Date Mon, 23 Feb 2004 23:51:08 GMT
[ Resending, as there's been no discussion, and I'm afraid it may have
been missed. I need an answer soon. Thanks :) ]

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.

[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/

Mime
View raw message