httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: very brief sketch of configure interface and autoconf foo to support shared MPMs
Date Tue, 07 Apr 2009 15:05:54 GMT
On Tue, Apr 7, 2009 at 10:31 AM, Nick Kew <nick@webthing.com> wrote:

> Jeff Trawick wrote:
>
>> Comments on interface or the minimal implementation details?
>>
>>
>  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.


Anything that uses the autoconf build is in scope.

no-threads could mean
* platform really doesn't have threads that APR supports
* APR was built with --disable-threads to work around some problem

Distinguishing between [!]have-APR_POLLSET_THREADSAFE is more complex, but
is required based on the collective desire to default to event, which I
interpret as "default to event where it has a chance of working."

In the world where we need that sort of logic to see if event can be
enabled, distinguishing between threads/no-threads doesn't seem to be an
unreasonable level of complexity.  And I hope that such a decision could
turn into

if event is in list of MPMs that work
  use event
elsif worker is in list of MPMs that work
  use worker
else
  use prefork
fi

with each individual MPM having determined if it can work and added itself
to the list of available MPMs if it can.


>
>  * Prefork always needs to be available, so users who configure
>   non-thread things like mod_privileges or PHP can switch
>   painlessly to it.


I suggest punting the prefork issue to a new thread, and I'll claim that the
selection above, which is a practical expansion of the current default in
trunk, is just an example of what we should be able to accomplish with
better MPM configure information, based on the whims of the group at the
time ;)


> 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.


This is just the build-time selection.  We'll still default to building a
statically-linked MPM for a while longer, at least until conf file
implications can get straightened out.




>
>  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.


no serious thoughts here ATM; modules have been checking for multi-threaded
children with ap_mpm_query() since 2002; perhaps a search for ap_mpm_query()
could be instructive to see what other absolute requirements some modules
have on the MPM

Mime
View raw message