Brian Pane <[EMAIL PROTECTED]> writes: > Jeff Trawick wrote: > > >Brian Pane <[EMAIL PROTECTED]> writes: > > > > > >>To continue the recent discussions on the problems in the current > >>apr_poll API, here's a patch for apr_poll.h that illustrates my > >>proposed fix. > >> > >>What I'm proposing here is to split the API into two parts: > >> > >> - A lightweight, single-function poll API for use (only!) > >> with very small sets of descriptors. > >> > > > >Do we really need this API? What is the sort of APR application for > >which the heavy-duty API is harmful? > > > > But the > main limitation of the general-purpose API is that, because it involves > some memory allocation, you can't use it for spontaneous, one-time poll > calls (like checking for readability on a single input socket if read > just returned EAGAIN) unless you can guarantee that the number of such > calls during the lifetime of the request pool has an upper limit.
This is the sort of thing I thought we'd start discussing a couple of hours ago :) The current implementation is useful if the user has to find out if the socket is readable/writable WITHOUT CONSUMING THE DATA and it is inconvenient to keep track of the APR representation of the pollset. If they are going to turn right around and consume the data then they might as well play with socket options and call apr_recv(). If it is convenient to keep track of the APR representation of a pollset, then it doesn't matter either way. I'm not sure that I see the compelling use-case but for various reasons it is probably best for me to assume that there are plenty of them. Hopefully having a separate API won't be confusing to APR programmers. ugh :) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
