apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <c...@force-elite.com>
Subject Re: [PATCH] sys_epoll Support for apr_pollset
Date Sun, 30 May 2004 21:52:08 GMT
On Sun, 2004-05-30 at 13:26 +0100, Joe Orton wrote:
> Interesting... some nits:
> 
> - C++ // comments bad ;)
> - CPP #directives must not have leading whitespace before the #

Fixed in the updated patch.

> - needs to cope with the fact that glibc implements epoll* returning 
> ENOSYS or whatever on 2.4 kernels IIRC, via autoconf or runtime checks

I would prefer doing this in autoconf, unless people are willing to
accept a much larger patch that could make the pollset back end
selectable at runtime.  The other issue with this is if APR was built on
a machine running 2.6, it might not be usable on a machine with 2.4.
That would be the other advantage of making the pollset back end runtime
selectable.  

Another goal of mine is to make a KQueue() based back end for FreeBSD
sooner or later.

> An issue I mentioned before w.r.t. removal of apr_poll() in HEAD: this
> type of implementation will surely end up being slower than using poll()
> for polling on small numbers of fds (a not uncommon case), due to the
> fact that it requires three rather than one system call?  Some
> benchmarks might be interesting.

I did a simple benchmark with an epoll enabled HTTPd 2.1 yesterday.
[mostly to see if it all worked correctly :) ]

It did a few transactions a second _faster_ than a normal poll() based
HTTPd 2.1.  Not significantly better or worse for Apache's common case
of not very many sockets.

Maybe later this week I can make up some more official benchmarks. 

> I wondered whether apr_poll() should remain using poll() with it's low
> constant overhead, and the apr_pollset_* interface alone should use the
> high-constant-overhead interfaces like epoll or /dev/poll?

Maybe.  I don't think poll's overhead is much less than epoll.  We will
have to benchmark it to find a real answer.

-Paul Querna

Mime
View raw message