httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul J. Reder" <rede...@raleigh.ibm.com>
Subject Re: Scoreboard redesign
Date Thu, 17 May 2001 16:22:56 GMT
Jim Jagielski wrote:
> > > Don't we have a 'generation' number on each process?
> >
> > yep.
> >
> 
> That ain't the problem. During this time we would need to keep
> the memory for the old scoreboard viable, as well as pointers to
> it, while creating a newer larger scoreboard and then having the
> parent process also "know" about this new area, and pointers to
> it. So we'd need some sort of scoreboard scoreboard for the
> parent process, since the parent process will need to
> continue to control/monitor both generations. Each generation
> will have it's own, distinct scoreboard, which adds a lot of
> complexity IMO.

It shouldn't add much complexity. The processes keep track of the
generation. There is already code to do cleanup when the last
worker of the last process leaves. Any shmem cleanup can piggy back
off of that. As for keeping track of the old vs new scoreboards,
that just isn't even a problem with the new design. All of the 
processes and workers are chained together in a linked list. The
list doesn't care how the elements were allocated, or whether they
came from the same shmem allocation.

The concerns of old vs new shmem relate more to the current
scoreboard implementation where it is one big chunk that is 
accessed only via contiguous regions.

-- 
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it.  Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein

Mime
View raw message