On Tue, Apr 7, 2009 at 10:31 AM, Nick Kew <[email protected]> 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
