httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: [PATCH] mpm_query
Date Wed, 11 Apr 2001 18:11:26 GMT
On Wed, 11 Apr 2001, Sander van Zoest wrote:

> On Wed, 11 Apr 2001 wrote:
> > > What happens when you have incompatibility on a particular platform with
> > > a MPM? It shouldn't just segfault, there should be a way to exit cleanly
> > > explaining why this particular module or piece of code can not run with
> > > the MPM used and the platform.
> > If there is a compatability problem between a platform and an MPM, then we
> > currently do not allow that MPM to be compiled on that platform without
> > direct intervention from the person compiling the server.  For example, on
> > FreeBSD, we do not compile with threads unless the admin tells us we have
> > to.
> Right, I guess I didn't really phrase my question the right way.
> How would you determine this incompatibility if you are a DSO module trying
> run on Apache HTTP 2.0? Let say a module can only run on prefork, for
> example.

Modules that hard-code which MPMs they support based on name are broken.
The name doesn't MEAN anything.  Modules should be determining if they
work based on the properties of the MPM.  Using the name means that they
need to be modified and re-compiled whenever a new MPM is released.  I am
not interested in supporting broken modules, especially not when it is
easier to support a working implementation.

> > > The more accurate information you have in the noc the better. Why monitor
> > > if you do not know what you are monitoring?
> > The problem is that the MPM name is not accurate.  We have a habit of
> > changing names of things.  The MPM properties are the best way to
> > determine the behavior of the MPM IMNSHO.
> Just because the MPM name isn't an accurate discription of what the properties
> are of an MPM doesn't mean it could not useful to know what the MPM name is?

I have asked for how it is useful.  I haven't heard an answer yet that
can't be determined either from the extension I have suggested.

> We should also keep in mind 3rd party MPMs such as the SGI STM MPM which
> might accurately describe the MPM by it's name, but it is an identifier that
> could point to the origin of the  MPM.

This is best determined by looking at the Server String.  We are talking
about how to programitically get this information.  If you are looking for
where the MPM came from, that should be in the server string, not
retrieved from the MPM through the query interface.  The query interface
was designed to retrieve the run-time properties of the MPM.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message