"Ryan Bloom" <[EMAIL PROTECTED]> 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 code,
> 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.*
Hopefully everybody agrees that the current implementation is harmful
for big pollsets.
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.
> > I suspect that rebuilding the abstract pollset (apr_pollfd_t array) in
> > its entirety after calling poll() is harmful to Apache, which is only
> > going to process the first match.
>
> I am unable to parse this at all. If you are talking about the current
> implementation, then one of the advantages is that you don't need to do
> 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?
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
