Run-time selection of poll implementation

[Tollef Fog Heen <tf...@err.no>]

Hi,

Currently, apr chooses whether to use epoll, kqueue, port, select or
poll at build-time.  This works quite well if your apr library is only
used on hosts with the same capabilities as the one you built on.
However, if you build on Linux 2.6 and try to use the binaries on
Linux 2.4, they don't work (due to the epoll interface not existing on
2.4).  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392373 is an
example bug report which shows the problem

To work around this, I have written a patch that does the selection at
runtime.  It has a small performance overhead (a function call and a
switch/case statement).  The alternative is to use function pointers
(initialised from apr_initialize), but this will break the ABI as well
as probably not being faster than a wrapper function.

I have no experience with kqueue and port-based systems, so this patch
may or may not work on platforms using those interfaces.  I have tried
to write sensible implementations, but they are untested and probably
require some changes.  I have not checked whether this is applicable
to OS/2 as well, but I don't think it is.

http://err.no/patches/apr_runtime_detection_poll.diff is a diff
against current SVN.  The same patch is attached.

Feedback, positive or negative, is appreciated.
-- 
Tollef Fog Heen                                                        ,''`.
UNIX is user friendly, it's just picky about who its friends are      : :' :
                                                                      `. `' 
                                                                        `-  

Re: Run-time selection of poll implementation

[Joe Orton <jo...@redhat.com>]

On Mon, Oct 16, 2006 at 12:25:23PM +0200, Tollef Fog Heen wrote:
> Joe Orton skrev:
> >On Sat, Oct 14, 2006 at 09:04:34PM +0200, Tollef Fog Heen wrote:
> >>Currently, apr chooses whether to use epoll, kqueue, port, select or
> >>poll at build-time.  This works quite well if your apr library is only
> >>used on hosts with the same capabilities as the one you built on.
> >>However, if you build on Linux 2.6 and try to use the binaries on
> >>Linux 2.4, they don't work (due to the epoll interface not existing on
> >>2.4).
> >
> >Of course, so don't do that.  If your lowest supported kernel revision 
> >is 2.4, then you have to build on a 2.4 kernel so APR won't use any 2.6 
> >features.  Otherwise you have to force particular choices by doing e.g. 
> >"export apr_cv_epoll=no" before running configure, to prevent detection 
> >of 2.6 features.
> 
> Wouldn't it be better if APR chose at runtime instead of just 
> segfaulting like it does today?

The SIGSEGV is not an APR problem, see e.g.:

$ grep -1 apr_pollset_create server/mpm/prefork/prefork.c
    /* ### check the status */
    (void) apr_pollset_create(&pollset, num_listensocks, pchild, 0);

Re: Run-time selection of poll implementation

[Tollef Fog Heen <tf...@err.no>]

Joe Orton skrev:
> On Sat, Oct 14, 2006 at 09:04:34PM +0200, Tollef Fog Heen wrote:
>> Currently, apr chooses whether to use epoll, kqueue, port, select or
>> poll at build-time.  This works quite well if your apr library is only
>> used on hosts with the same capabilities as the one you built on.
>> However, if you build on Linux 2.6 and try to use the binaries on
>> Linux 2.4, they don't work (due to the epoll interface not existing on
>> 2.4).
> 
> Of course, so don't do that.  If your lowest supported kernel revision 
> is 2.4, then you have to build on a 2.4 kernel so APR won't use any 2.6 
> features.  Otherwise you have to force particular choices by doing e.g. 
> "export apr_cv_epoll=no" before running configure, to prevent detection 
> of 2.6 features.

Wouldn't it be better if APR chose at runtime instead of just 
segfaulting like it does today?

- tfheen

Re: Run-time selection of poll implementation

[Joe Orton <jo...@redhat.com>]

On Sat, Oct 14, 2006 at 09:04:34PM +0200, Tollef Fog Heen wrote:
> Currently, apr chooses whether to use epoll, kqueue, port, select or
> poll at build-time.  This works quite well if your apr library is only
> used on hosts with the same capabilities as the one you built on.
> However, if you build on Linux 2.6 and try to use the binaries on
> Linux 2.4, they don't work (due to the epoll interface not existing on
> 2.4).

Of course, so don't do that.  If your lowest supported kernel revision 
is 2.4, then you have to build on a 2.4 kernel so APR won't use any 2.6 
features.  Otherwise you have to force particular choices by doing e.g. 
"export apr_cv_epoll=no" before running configure, to prevent detection 
of 2.6 features.

epoll is not the only 2.6 feature which APR will depend on at runtime if 
detected at build time, I can think of HAVE_TCP_NODELAY_WITH_CORK also, 
probably others too.

joe