apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: svn commit: r178386 - /apr/apr/trunk/build/apr_hints.m4
Date Wed, 25 May 2005 07:52:18 GMT
On Wed, May 25, 2005 at 12:10:41AM -0700, Paul Querna wrote:
> Joe Orton wrote:
> >>This could all be mute if we added a KQueue backend for apr_poll().  I
> >>had the code to do it at one time, I will look at adding it later this week.
> > 
> > apr_poll() is not used by apr_wait_for_io_or_timeout().
> > 
> Yep. It uses poll() directly, or a pollset.  Maybe we should just
> preload WAITIO_USES_POLL to 0 on darwin, instead of killing poll completely?

Either it's broken or it's not, let's decide on one and at least be
consistent ;)

> > But making apr_poll() use a kqueue-like interface is a really bad idea
> > anyway, as I've argued before.  apr_poll() should be efficient to use
> > occasionally or for small numbers of fds; and will be necessarily faster
> > than apr_pollset_* in those cases since it requires just one system call
> > - no overhead for setting up and tearing down the kqueue/epoll/... 
> > interface.
> Perhaps, but if they could be cached, and re-used, it is faster if we
> will be doing it multiple times.  

The apr_poll() interface doesn't allow that; that's the whole point. 
This is a feature not a bug.  One size does not fit all.  etc ;)

> On FreeBSD, I commonly saw kqueue to have about 20% lower latency than
> poll().

With a single fd in the pollset?


View raw message