httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: Scoreboard redesign
Date Wed, 16 May 2001 15:22:22 GMT

> > > For the time being, the shared storage will still be allocated in a "big
> > > chunk" up front (until we can figure out how to allocate and free smaller
> > > chunks). We will unfortunately still be allocating more than is usually
> > > needed, but will now be able to avoid allocating the (bigger) part related
> > > to mod_status if it isn't loaded. So overall it should usually be a
> > > memory savings.
> >
> > Seems to me, this will break gracefull restarts if you're adding
> > mod_status at that time, since the scoreboard is allocated at initial
> > boot and not at restarts.
> 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, 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

> 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, for the same reason as the one listed above.

> want to use binaries).  Getting rid of the shmem for the previous
> generation might be the most challenging problem.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message