httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject very brief sketch of configure interface and autoconf foo to support shared MPMs
Date Tue, 07 Apr 2009 13:13:25 GMT
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

MPM config.m4 files use the normal APACHE_MODULE() macro to control
inclusion and static/dynamic and trigger platform checks

--with-mpm and --with-mpms-shared enable one or more of the MPMs by setting
the appropriate enable_FOO variables

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

but somehow code should be reused so that the default MPM decision and the
check to explicitly enable event (as an example) use the same feature
checks.

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?

FWIW, the list of MPMs that can work on the platform could be used to
implement --with-mpms-shared=most.

Ugh!

Mime
View raw message