apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: New apr_poll() implementation
Date Tue, 09 Jul 2002 20:52:56 GMT
> From: Ryan Bloom [mailto:rbb@covalent.net]
> Sent: 09 July 2002 15:46

>> From: Ryan Bloom [mailto:rbb@covalent.net]
>>> 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
>>>> long 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.
> I should clarify this.  The whole point of this change, is that the user
> can do the following:

> That code will work.  Notice that no where before the apr_poll, did we
> tell the poll implementation the size of the pollset.  Nor can we.  This
> is where the real performance benefits of this patch come in.  Because
> the user has complete control over the pollset, we can remove all but
> one pool allocation, and that one can be removed with an optimization
> for small pollsets.
> Now, we can make macros to add sockets and files, but we should not EVER
> be telling APR how many descriptors we are polling until we call
> apr_poll().  The functions that currently setup the pollset and add
> sockets and set events and revents are all deprecated, and were only
> left in the patch to allow for as much source backwards compat as
> possible while the patch is being discussed.  Once the patch has been
> committed, I will go through the source and start to remove those
> functions completely.  The only real example of apr_poll() that is a
> part of the patch is wait_for_io_or_timeout.  I probably didn't make
> that clear enough.

Ah, no.  Without the accessor functions it doesn't make much sense
to store the pollset size in apr_pollfd_t.  I surely didn't see removing
the accessor functions comming.  Not sure if I like that (+0, -0).  I can
see the perf benefit, but if it makes for a better API, I don't know.

Oh well, my $0.02,


View raw message