httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <I...@cnet.com>
Subject RE: Scoreboard redesign
Date Wed, 16 May 2001 15:08:02 GMT


> -----Original Message-----
> From: Greg Ames [mailto:gregames@remulak.net]
> Sent: Wednesday, May 16, 2001 6:49 AM
> To: new-httpd@apache.org
> Subject: Re: Scoreboard redesign
> 
> 
> 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.
> 

Don't we have a 'generation' number on each process?
maybe there could be something at the thread level which says what generation it is using.
so when a gracefull restart happens, as each thread gets notified, and finishes it's current

request it will bump up it's generation count.

then you have a GC thread/process (also fired off by the graceful restart) which is responsbible
for
dealloctating the sharedmemory (or any other resource needed to be cleaned up). It would wake
up 
every second, look to see if there are any threads still on the generation it cared about,
and
if not it would be safe to deallocate the resource.

so if you have a long running request, the GC thread will poll every second, and the memory
will
eventually get released when the thread dies. (or you could kill the thread after say 12 hours)

or am I missing something?

> Greg
> 

Mime
View raw message