Jeff Trawick wrote:
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 :)
hmmm...another characteristic of the use case in which the current
API is useful is that there's exactly one descriptor involved. Would
that yield a useful simplification of the two-API plan? I'm thinking
of something like:
- apr_pollset API for general-purpose use (abstract interface,
does its own memory management, etc)
- lightweight API that just checks a single descriptor for readability
or writability
Of course, if we can only come up with a single use case for the second
API, and it happens to be apr_wait_for_io_or_timeout(), then let's just
inline the poll/select call there and forget about the lightweight API
until we find another use case.
--Brian
