apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: New apr_poll() implementation
Date Tue, 09 Jul 2002 13:33:47 GMT
> From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
> On Sat, Jul 06, 2002 at 12:11:59PM -0700, Ryan Bloom wrote:
> > parameters.  I would like to fix that mistake for apr_poll now, as
> > as we are changing the implementation.
> Getting back to this conversation for a brief second, I think the
> additional parameter with the fd count is unneeded (but for a
> different reason than IN/OUT).  The count should be stored in
> apr_pollfd_t - it does not need to be passed into apr_poll().

The count should absolutely NOT be stored in apr_pollfd_t.  That is user
owned structure, not an APR owned structure.

> Since you have to call apr_poll_socket_{add|remove}, you can't
> populate apr_pollfd_t on your own (which is something you can do
> with pollfd, hence why poll() needs the count).  apr_poll_setup()
> should take the maximal size and init the counter to 0.  As fds
> are added or removed, the counter is adjusted.

The apr_poll_socket_(add|remove) are deprecated, and actually aren't and
shouldn't be used.  The whole point of this patch, and the reason it
performs better is that the apr_pollfd_t structure is transparent, and
it is meant to be allocated and owned by the user.

> BTW, we also need apr_poll_file_{add|remove} (seems to be missing
> from rbb's patch).  -- Justin

We don't need it, although we may create it, as a macro.  As proof that
we don't need either however, look at wait_for_io_or_timeout.  That
function is a consumer of apr_poll now, and it acts just like any
consumer outside of APR should act.  It does not add sockets or files
with functions.

The only reason the other functions are still in the code, is for
backwards source compat.  They have been marked as deprecated in my
tree, although I did it after I posted the patch, because I forgot about


View raw message