httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: [PATCH] allow MPM to change HARD_SERVER_LIMIT/HARD_THREAD_LIMIT at startup
Date Tue, 18 Dec 2001 04:37:22 GMT
On Monday 17 December 2001 08:30 pm, Jeff Trawick wrote:

Cool.  Thanks for showing me what I was missing.  In that case, +1.
I am not sure how much more useful this is than what we have now,
but it is a step in the right direction.


> Ryan Bloom <> writes:
> > I'm missing something major here.  This patch doesn't remove the dependence
> > on HARD_SERVER_LIMIT and HARD_THREAD_LIMIT, it just hides the actual
> > macros.  The dependence is still there, but it is queried through the ap_mpm_query
> > function.  In fact, you are computing the size of the scoreboard based on those
> > values.
> Yep.  The missing piece is a way for an MPM to return something
> dynamically-configured from the mpm query function, instead of just
> returning HARD_SERVER_LIMIT/HARD_THREAD_LIMIT.  As I mentioned in the
> brief description, I didn't want to clutter expected discussions of
> the user interface for setting those values with the bulk of the code.
> What I meant from the subject line is that with this patch an MPM can
> *choose* to implement softer limits for servers and threads.  In other
> words, with this patch the core code now gives an MPM the power to
> allow the admin to set those limits at startup.  How we choose to do
> that with our own beloved MPMs remains to be seen.
> I would doubt that prefork would bother with it since it doesn't take
> so much scoreboard storage to support a wide range of values for
> MaxClients, and so prefork.c would continue to use the 
> I'd think that both perchild and worker would benefit from it.  I
> dunno about other MPMs.
> > Having said that, the changes to mod_status are all goodness, and I would
> > encourage those to be committed immediately, even without the other stuff. 
> > This has been on my list for a while, but I kept forgetting about
> > it.
> I'll do that shortly.
> > I would appreciate an explanation of how this removes the H_S_L and H_T_L
> > dependance though.
> easy explanation: that capability isn't here (yet)
> -- 
> Jeff Trawick | | PGP public key at web site:
>              Born in Roswell... married an alien...


Ryan Bloom
Covalent Technologies

View raw message