Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Sender: gregames@Mail.MeepZor.Com
Message-ID: <3B028545.8C803FC@remulak.net>
Date: Wed, 16 May 2001 09:48:53 -0400
From: Greg Ames <gregames@remulak.net>
MIME-Version: 1.0
To: new-httpd@apache.org
Subject: Re: Scoreboard redesign
References: <200105160446.AAA12313@devsys.jaguNET.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jim Jagielski wrote:
> 
> Paul J. Reder wrote:
> >
> > 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
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
want to use binaries).  Getting rid of the shmem for the previous
generation might be the most challenging problem.

Once we get this stuff figured out, it would be most excellent if some
of the layered memory system folks would jump in and help out with
managing the individual small pieces of shared memory.

Greg