httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <I...@cnet.com>
Subject RE: [PATCH] mpm_query_2
Date Thu, 12 Apr 2001 15:58:22 GMT
could you have a mpm group of functions to determine the
capabilites of the installed MPM.
a function to show the name of it, 
it's threading model
and maybe a string description of the configuration of it.

so for example

for mpm_prefork it would be "pre-fork" as a threading model, and it would read "30 At Start,
Max of 50 (Hard: 400), ... "
where mpm_threaded would be "pthread" as a threading model, and it would say something like
"5 processes, each 10 threads"

maybe also a set of 'cabaility' functions

mpm_has_shared_mem
mpm_has_multiple_contexts_per_process (for threaded)

that way a module writer could query the MPM for what kind of capabilities it has, and could
adjust it's own behavior accordingly.



> -----Original Message-----
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Thursday, April 12, 2001 8:38 AM
> To: new-httpd@apache.org
> Subject: Re: [PATCH] mpm_query_2
> 
> 
> On Thu, 12 Apr 2001, Harrie Hazewinkel wrote:
> 
> > rbb@covalent.net wrote:
> > >
> > > On Thu, 12 Apr 2001, Harrie Hazewinkel wrote:
> > >
> > > > 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.
> > >
> > > -1 for returning the string from this function.  It makes 
> the function
> > > harder to read and to use.  If you absolutely must have a 
> way to query the
> > > MPM name, then use a separate function for it.  Something like
> > > ap_show_mpm() like Sander suggested yesterday.
> >
> > You definitly have not understood the use of it.
> > But that does not matter. I know you act like the APACHE
> > 2.0 police.
> >
> > I now start thinking that the MPM_TYPE should be an MPM_DESCR.
> > and for what the ap_show_mpm goes it can use the mpm_query to
> > provide the proper values. IMHO, the ap_show_mpm
> > is a not wrapper around ap_mpm_query.
> 
> What?!?  How have I not understood the use of it?  I have 
> simply said that
> adding the ability to return a string from that function 
> makes the code
> unnecessarily ugly.  I have suggested using a separate function for
> getting the same information that you want.  I am not removing
> functionality, I am asking to make the code and the API simpler.
> 
> ap_show_mpm should definately not be a wrapper around 
> ap_mpm_query.  if
> you are going to do that, then just don't create ap_show_mpm. 
>  The goal is
> to keep the API simple, not to make it overly complex by 
> having two ways
> to get the exact same information.
> 
> Ryan
> ______________________________________________________________
> _________________
> Ryan Bloom                        	rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> --------------------------------------------------------------
> -----------------
> 
> 

Mime
View raw message