httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul J. Reder" <>
Subject Re: Suggested direction for fixing threaded mpm thread startup.
Date Tue, 17 Apr 2001 02:45:25 GMT wrote:
> There is just the one scoreboard, and the parent basically scans through
> the entire scoreboard, looking for the longest run of contiguous blocks.
> Once it has that number, it creates a child process that has that number
> of threads.  In order to do this, it will need to modify a couple of
> values before forking, and then reset them to the original values.
> The only problem I see, is if all of the processes have a large number of
> hung threads.  I am not sure that is a situation we need to fix though.
> If all of your processes are hung, we have the same issue.

Sorry to start this conversation and leave, but I am actually traveling at
the moment and can only get to e-mail sporadically.

I can see the problems that Ryan pointed out with my original idea. I had
been thinking in theoretical terms focussing on the perform_idle_server_maintenance
code. The impact on the scoreboard also needs to be looked at.

Ryan, doesn't your solution provide some indexing issues? I need to spend a
little time looking at the way processes/threads end up in the scoreboard,
but I thought the initial and subsequent indexes were computed from the
process slot and thread slots within that.

If my memory is correct, the temp servers (child_main) would likely be 
starting its indexes in a non-computable location.

What if each thread was assigned a tid based on the scoreboard index instead
of the index of the thread within its child_main process (see tid assignment
in chid_main of threaded.c). Would this allow the insertion of new threads in
random available slots in the scoreboard? Would we be able to start a new
server if there were threads_per_child open slots in the scoreboard (even if
they were non-contiguous)? We could then use the tid to index into the
scoreboard for info and updates.

I believe that the code now counts up thread states regardless of the process
that spawned them (i.e. how many total idle threads are there). If my memory
is correct then there is not a strong reason to keep the threads for a process
in a fixed contiguous space.

Any possibilities here?

The problem that I see is that the threaded code still looks at the world from
a process perspective. I think something that was just pointed out is that it
isn't just the mpm that is that way, the scoreboard contributes as well. I was
looking at changing the mpm because it was self contained. The scoreboard,
unfortunately, is common and therefore not as malleable.

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

View raw message