httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sander van Zoest <san...@covalent.net>
Subject Re: [PATCH] mpm_query
Date Wed, 11 Apr 2001 18:37:06 GMT
On Wed, 11 Apr 2001 rbb@covalent.net wrote:

> > 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.
  
I am not suggesting to use the name to determine compatibility, the name
is really just an identifier to what you would call the MPM in general
terms. I totally agree that the properties should be able to determine
compatibility.

I would say then that the properties of an MPM should be extensible and
flexible, because what happens when you have multiple types of threaded
MPMs on the same platform and such. We really can't determine all the
possible MPM properties that might exist in the future.

If you tell a user that they need a threaded MPM instead of a process based
MPM, then they need to somehow figure out the name of the MPM they want to
use as the threaded MPM when they recompile. An --enable-threads isn't good
enough. Are we talking pthreads, sgi's state threads etc.

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

One place knowing the name of the MPM is useful is just to be able to
provide a way of quickly describing an MPM without necessarily describing
it by it's properties. If we do not allow for discovering the name
programmaticly then we would have to have a matrix somewhere that finds
out the name of the MPM just so people can quickly know which it is.

Think of it more like an ID, not necessarily a name that accurately describes
the MPM.

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

So a logging module or monitoring interface should parse the Server
String to find out the name of the MPM? I really do not understand the
harm by allowing the name of the MPM to be programmaticly determined
without having to go through the hassle of parsing the Server String.

An ap_show_mpm_name() similar to ap_show_modules() and ap_show_directives()
seems to makes sense to me ontop of the mpm_query interface for properties.

--
Sander van Zoest                                         [sander@covalent.net]
Covalent Technologies, Inc.                           http://www.covalent.net/
(415) 536-5218                                     http://Sander.vanZoest.com/


Mime
View raw message