Bill Stoddard wrote:
>
> Here is another idea for solving the scoreboard problem....
>
> Today, the scoreboard serves two purposes: as a place to hold and maintain child
>process status as
> used by perform_idle_server_maintenance() and as a place to hold bytes used by
>mod_status. And the
> main "problem" is how to manage the storage used by the scoreboard. Here is a rough
>sketch of my
> proposal:
>
> First, seperate out the scoreboard into two pieces, one piece used by
> perform_idle_server_maintenance() to maintain child processes status and the other
>piece for use by
> mod_status. The storage required for the idle_server_maintenance piece is reduced
>by an order of
> magnitude. Now we have two problems to solve:
>
> 1. How to manage new process creation when idle_server_maintenance() detects a child
>process is in
> shutting down gracefully...
> Basically this problem is addressed by allocating a pm_scoreboard larger (say 5x
>larger) than you
> need at steady state. If you detect a process is shutting down, create a new process
>and give it a
> place in the pm scoreboard. Remember, since a pm score entry is much smaller than
>before, you can
> have a lot more of them w/o using gobs of memory. Can place upper limits on the
>number of child
> processes (and the number of pm score slots) but you probably will not be memory
>constrained due to
> the pm score size. This gives us a lot of wiggle room to play with algorithms for
>managing the pm
> score.
Can I assume that this is allocated and owned by the mpm?
>
> 2. How to maintain bytes used by mod_status?
> This is a bit tricker and there are multiple possible solutions. The key is to
>manage the storage
> such that entries can be selectively reused. One possible implementation...
>
> A pm_score entry (one per process) contains in addition, to a status field, an array
>of pointers,
> each pointing to a mod_status scoreboard slot (ms_score). There is a pointer per
>thread in the child
> process.
>
> struct pm_score {
> int status;
> ms_score *[THREADS_PER_CHILD];
> }
The only thing I would posssibly like to add to the ms_score struct (listed in the
subsequent note)
is to store the tids. Right now the threaded mpm has to allocate an additonal struct
to store the
tids of its kids for join purposes.
>
> As threads exit, they set a field in ms_score indicating that they are done using
>the entry and that
> it can be put on a free list to be reused by the parent in a new process. In the
>event of a child
> seg fault, the parent can assume ownership of all the ms_score slots and put them on
>the free list.
> I think this can be done w/o requiring any locks.
This sounds like a good basic idea to me. It hits at the source of some of the
problems I have
been running into. The mpms need some mpm specific process/thread info to be handled
in a safe
manner for dealing with cleanup while the status processing needs generic, vaguely
accurate info for
reporting and doesn't need to worry too much about safety.
--
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
