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):
if have-APR_POLLSET_THREADSAFE
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
