httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Re: very brief sketch of configure interface and autoconf foo to support shared MPMs
Date Tue, 07 Apr 2009 14:31:58 GMT
Jeff Trawick wrote:
> Comments on interface or the minimal implementation details?
> traditional:
> --with-mpm=FOO includes the FOO mpm, statically linked
> temporary hack:
> --with-mpm=shared avoids building/linking in an MPM
> future:
> traditional --with-mpm is retained; 
> also support --with-mpms-shared=MPM-LIST; this has to be used to avoid a 
> statically-linked MPM, since otherwise you get --with-mpm=some-default

+1.  Should lead smoothly to the packagers adopting a sensible strategy.

> Externally, the selection of the default MPM should match this logic 
> (slight expansion on Jim's simple default=event change):
>   use event
> elsif have-APR_THREADS
>   use worker
> else
>   use prefork
> fi

Couple of thoughts:
  * Does it need that level of complexity?  I mean, for example,
    is there any supported platform since FreeBSD 4 where APR
    builds without threads?  And presumably non-*X platforms
    lie entirely outside your scope here.
  * Prefork always needs to be available, so users who configure
    non-thread things like mod_privileges or PHP can switch
    painlessly to it.
Do I take it you meant we default to building dynamic, and the
above selection applies only to default-httpd.conf?  In which
case, windows et al should probably be included in the discussion.

> An MPM's autoconf logic should be able to report whether the MPM can run 
> on the platform (as an aid to selecting the default MPM) as well as 
> handle its selection, explicit or by default, but those run in different 
> phases, requiring multiple config*.m4 files for an MPM.  Any concerns 
> with having two config*.m4 files per MPM, assuming that it actually 
> works?  Or, can you think of a better way to encapsulate whether or not 
> an MPM can run on the platform within the MPM itself?

I wonder if it's time for a fresh look at ap_mpm_query.  Modules can
make individual checks and refuse to run with an incompatible MPM.
But if we reach the point where that becomes more common - as seems
likely with some of the proposals floating around - we could do
with a declarative version.  Maybe ap_mpm_require(...) for modules,
and the core can then query the MPM and exit with a decent
error report if something is unsatisfied.

Nick Kew

View raw message