Pretty much +1, thanks Harrie. Note that you ought to be using apr_int32_t
for something more explicit. As I've said, I like returning the MPM string.
Suggest we might even have a 'version' for MPM's in that string [subrevision
could be bumped by CVS itself.]
I keep having visions of MPM's that are maintained outside the core, so it
may not be realistic to assume that mpm_foo and apache v2.0.35 correspond.
Bill
From: "Harrie Hazewinkel" <[EMAIL PROTECTED]>
Sent: Thursday, April 12, 2001 9:27 AM
> Hi all,
>
> I have made a new patch for the mpm_query functionality.
>
> 1) This patch extends the information that can be retrieved.
> 2) It also allows to return an MPM_TYPE which is a string.
> This is used to provide some additional information
> about the MPM used. It even could be used by an MPM
> developper to provide an arbitrary human readable
> string which can be used for management purposes.
> 3) The AP_MPMQ_IS_FORKED and AP_MPMQ_ISTHREADED now return
> a capability. It now can return 3 values:
> - NOT_SUPPORTED = 0
> - STATIC = 1
> - DYNAMIC = 2
> This mechanism is to enable other module to figure
> out the capabilities for threading and forking.
> If one wants to have the same results as previous
> (which was not more then a true/false) you can
> consider value 0 (not supported) as false and
> static and dyniamc true.
> There is actually no need to make even a capabilities
> value besides the IS_FORKED and IS_THREADED.
>
>
> The patch is attached (in unified form and does not rely
> on the previous mpm_query).
