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 17:41:35 GMT
On Thu, 17 May 2001, Paul J. Reder wrote:

> wrote:
> > You can't break graceful restarts with this change.  The problem is that
> > adding mod_status using a graceful restart is actually a common occurance.
> > People do that because they are having problems with the server, and they
> > want to monitor it, but they don't want to kick people off the server.
> >
> > Until the shared memory problem is solved, I am -1 for this change.
> I hadn't thought about the debugging aspects of turning mod_status on via a
> restart. Disallowing mod_status on restarts was one of two documented
> possibilities (the one that would allow the memory to be saved). The other
> possibility is to continue to always allocate the memory so that mod_status
> can come and go. I assume that your veto is on the first option and not
> the second since the second is the way the code works now.
> Saving the unused mod_status memory was one side benefit of this design,
> not a required mainstay. If we can't reap this benefit now, I would hope
> that we can fix things eventually so that we can. It is not required now,
> it just happens to be a possible side benefit.
> Can you please clarify what you are vetoing so that I have an opportunity
> to encourage your support.

I am veto'ing the side effect of not allowing mod_status to be enabled on
a restart.  I dislike the complexity that this whole thing is adding.
Traversing an array for the current status of the server is very clean and
elegant.  I do not believe that a linked list will be as clean.  I am not
veto'ing the linked list, I just don't believe it will be as clean a

I would prefer to see a solution that allows processes to be created with
fewer threads than required.  In fact, that is probably the easiest
solution to the whole problem.  Let the child process handle it.

My understanding of the overall problem to solve, is that it is possible
for a single thread in a child process to keep that process slot from
being used for a new child.

Divorce the threads from the process, and this problem goes away.  For
example, take this scoreboard.

10	1	WAITING		...
10	2	WAITING		...
10	3 	BUSY		...

Now, assume we get a graceful restart request, the scoreboard goes first

10		STOPING		...
10		STOPING		...
10	3 	BUSY		...

This one child process could be busy for a while, but why not allow a new
child process to start, so that the scoreboard becomes:

11	1	STARTING	...
11	2	STARTING	...
10	3 	BUSY		...

The child can keep track of how many threads have already been started,
and once the last thread of PID 10 goes away, it can create the final
thread, so that the scoreboard becomes

11	1	WAITING		...
11	2	WAITING		...
11	3 	STARTING	...

Now, we keep the array design, which allows for a very simple
implementation that does not require any locking, and we get the ability
to do a real restart.  I do not believe that it will be possible to create
a linked list implementation without locking, because you will need to
traverse the list, and elements will be allocated and freed on the fly.

The only addition to the code needed to implement this design, is a second
table, private to the parent, with the same number of elements as the
scoreboard.  This array will be used to store the pids of processes that
are actually dying.  Because the parent is the only thing to modify the
array, there is no locking involved, and it allows, for two different
processes to share one process space in the scoreboard, assuming that one
of the processes is trying to die.

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

View raw message