httpd-dev mailing list archives

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

> > 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.

How are you going to deal with locking with this?  Don't tell me it
doesn't require any, because you are doing shared memory with a linked
list.  There will be locking considerations whenever you create a new
shared memory segment.


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

View raw message