httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: [PATCH] allow MPM to change HARD_SERVER_LIMIT/HARD_THREAD_LIMIT at startup
Date Tue, 18 Dec 2001 04:06:03 GMT

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.

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 would appreciate an explanation of how this removes the H_S_L and H_T_L
dependance though.

Ryan

On Monday 17 December 2001 07:30 pm, Bill Stoddard wrote:
> ++1
> 
> Removing the restriction of a compiled in HARD_SERVER_LIMIT and HARD_THREAD_LIMIT and
> doing it w/o requiring scoreboard locking as you have done is total goodness. Each MPM
can
> define defaults and possibly max limits, if that is what the MPM needs to do, or not.
> 
> Bill
> 
> > primary goal:
> >
> > be able to change equivalent of HARD_SERVER_LIMIT/HARD_THREAD_LIMIT
> > without rebuilding the server
> >
> > this is trivial to implement with the caveat that you don't allow the
> > admin to change it across a restart
> >
> > currently, to allow the admin a lot of choices in how they split httpd
> > threads among processes, lots of unused shared memory is required;
> > this is much worse with a threaded MPM than it ever was with
> > prefork/Apache 1.3 because the amount of resource consumed is
> > threads*servers
> >
> > what module code has to change with this patch?
> >
> >   *If* module is being bad and isn't using the MPM query API, it must
> >   start doing it, because we don't allow modules to see equivalent of
> >   today's HARD_SERVER_LIMIT/HARD_THREAD_LIMIT.  Hopefully third-party
> >   modules aren't doing that, because it is a problem that they must be
> >   rebuilt if somebody rebuilds/reconfigures httpd with different
> >   HARD_SERVER_LIMIT/HARD_THREAD_LIMIT.
> >
> >   *Otherwise* just a recompile is necessary to tell the C compiler to
> >   generate different code to walk through the scoreboard arrays.
> >
> > benefits:
> >
> > * we have an MPM query API; don't let the module bypass it
> >
> >   the changes below to mod_status keep mod_status from needing a
> >   recompile if you're using an MPM that is stuck with hard limits and
> >   you have to rebuild the server
> >
> > * an MPM needs power to implement softer HARD_THREAD_LIMIT /
> >   HARD_SERVER_LIMIT; since it is easy for the MPM to do that, don't
> >   stand in the MPM's way
> >
> > Of course I would want worker to be softer about these limits than it
> > is today but independent of that we should certainly allow somebody
> > to patch it or implement their own MPM that is nice in that regard.
> >
> > (The main reason there is no patch here to make worker do that is
> > because there are issues to discuss about the user interface which
> > shouldn't cloud the issue of being able to do such a thing.)
> >
> > One of the details of limiting HARD_SERVER_LIMIT/HARD_THREAD_LIMIT
> > to being the MPM's concern is that the way to do
> > ap_update_child_status() needed to change.  Now, there is a handle to
> > scoreboard information in the conn_rec which most code uses.
> > Currently that handle just has access to the server and thread indices
> > but with a few lines of code this could also have pointers to the
> > appropriate status structures.  That didn't seem important for the
> > current goal.
> >
> > Changes not here in the patch are necessary for MPMs other than worker
> > and prefork.  They need to get HARD_SERVER_LIMIT/HARD_THREAD_LIMIT out
> > of mpm_default.h and just refer to them locally.

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message