httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: Scoreboard redesign
Date Wed, 16 May 2001 20:29:36 GMT

> > > hmmm...more thought, code reading, and whiteboard doodling is called
> > > for.  Off the top of my head, I would think one of the config hooks in
> > > mod_status could allocate a big chuck of shmem for its use on every
> > > restart.  Then the new worker processes would see the Right Stuff as far
> >
> > You can't allocate on every restart,
>
> sure we can, if we are careful about cleaning up
>
> >                                       because if you do, the information
> > won't survive a restart.  Imagine the pathological case, where a single
> > request is very long-lived, and it happens to survive multiple restarts.
> > If we reallocate during each restart, we will lose the status of that
> > request.
>
> good point...easily solved I think.  "last guy out turns out the lights"
> - when the last process for generation x goes away, it's time to clean
> up generation x's huge chunk of shmem.
>
> >
> > > as pointers.  The core should also allocate a new chunk of shmem to
> > > represent the processes at restart time, so we can get rid of the
> > > HARD_SERVER_LIMIT stuff (it's a PITA...think of admins in big shops who
> >
> > Again, you can't do that,
>
> understand your concern, but it just requires code.

You are talking about adding a lot of logic that has very little benefit
IMO.  The purpose for these changes, are to remove HARD_SERVER_LIMIT, and
to make it easier to remove some shared memory if mod_status is not
loaded.  How big a hardship is HARD_SERVER_LIMIT, and how much memory are
we really talking about?

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------





Mime
View raw message