apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: [Request for comments] new poll API
Date Mon, 29 Jul 2002 17:42:12 GMT
> From: trawick@rdu88-250-182.nc.rr.com [mailto:trawick@rdu88-250-
> "Ryan Bloom" <rbb@covalent.net> writes:
> > > I suspect that rebuilding the native pollset (e.g., struct pollfd
> > > array) every time apr_poll() is called is harmful to Apache.
> >
> > It should actually perform better than the previous version of the
> > for small pollsets, which is what most people use with Apache.
> I started off agreeing that the new implementation is faster for small
> pollsets, but I'm not sure that is the case when you consider
> steady-state operations.  We save the overhead of the function call to
> look up the returned events after the poll call but we pick up the
> overhead of the internal call to get_event() just before poll() is
> called.*

That get_event() call can easily be removed in 99% of the cases (see

> If APR had a small-pollset API and a big-pollset API, I suspect we'd
> be better off in Apache just using the big-pollset API rather than
> deciding at run-time which API to pick since implementing a choice
> would likely introduce an extra function call which would erase any
> small benefit of being able to use the small-pollset API.

In how many situations would we actually need to use the big-pollset
API?  I would much rather just write the code to use the small-pollset
API, and possible #ifdef the big-pollset API.  It would be faster to use
the small-pollset API, and if you _must_ have the large-pollset, then
you configure for it.

> > > I suspect that rebuilding the abstract pollset (apr_pollfd_t
array) in
> > > its entirety after calling poll() is harmful to Apache, which is
> > > going to process the first match.
> >
> > I am unable to parse this at all.  If you are talking about the
> > implementation, then one of the advantages is that you don't need to
> > that anymore.
> Here is the code I referred to as "rebuilding the abstract pollset
> (apr_pollfd_t array):"
>     for (i = 0; i < num; i++) {
>         aprset[i].rtnevents = get_revent(pollset[i].revents);
>     }
> *yeah, calling from Apache to APR is more expensive than an internal
> APR call, but are we digging that deep to find the benefit?

This is a straight bit-mask check, and in most cases, can be optimized
out to a no-op.  We have to write the optimization, but 99% of the time,
the function call can be removed.  As for the first/all rtnevents
decision, Apache should be using all of the results.  We don't
currently, but we could and should.

View raw message