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 [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
