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: [EMAIL PROTECTED] Web: http://cataclysm.cx/
signature.asc
Description: Digital signature
