My last post wasn't as clear as it could be. Here is some code to help explain the data
structures...
/* Per thread scoreboard. Thread specific and used by mod_status */
typedef struct {
unsigned char status;
unsigned long access_count;
unsigned long bytes_served;
unsigned long my_access_count;
unsigned long my_bytes_served;
unsigned long conn_bytes;
unsigned short conn_count;
unsigned short life_status; /* Either SB_WORKING or SB_IDLE_DIE */
apr_time_t start_time;
apr_time_t stop_time;
char client[32]; /* Keep 'em small... */
char request[64]; /* We just want an idea... */
server_rec *vhostrec; /* What virtual host is being accessed? */
/* SEE ABOVE FOR SAFE USAGE! */
} thread_score;
/* Per process scoreboard. Used by Linux/Unix MPMs to do child process maintenance */
typedef struct {
unsigned char status; /* Child process status */
thread_score *ts[HARD_THREAD_LIMIT];
} proc_score;
typedef struct {
/* Global info */
ap_scoreboard_e sb_type;
ap_generation_t running_generation; /* the generation of children which
* should still be serving requests. */
proc_score[HARD_SERVER_LIMIT*2];
} ap_scoreboard;
> 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.
>
> 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];
> }
>
> 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.
>
>
> >
