On Thu, 21 Jun 2001, Paul J. Reder wrote:
> [EMAIL PROTECTED] wrote:
> > It will
> > require locking anytime somebody wants to walk the scoreboard, which means
> > that potentially the scoreboard will be run once a request. Think
> > mod_status and/or mod_snmp.
>
> This is just plain not true. The pointer to the worker is placed in the
> conn_rec for direct access. Neither the worker, nor the scoreboard need
> to be locked for the worker to be updated during a request. The request
> processing knows that the worker pointer is valid for the duration of
> the request. The request processing does not care about any other
> workers or processes during update. The status code doesn't care if the
> worker data is updated while it is doing a walk.
>
> The locking is only required during the time that a worker or process is
> being added or removed from the tree or mod_status is running. And the
> locking is only needed to keep those two events out of each others hair.
> Mod_status does not happen often, nor does adding/removing workers and
> processes.
This is exactly what I said. The scoreboard needs to be locked, whenever
it is walked, namely whenever mod_status or (potentially) mod_snmp is
called. Mod_status may only be called once in a while, but what about
mod_snmp? Does that walk the scoreboard every request? Remember, you
will also still need to logic to make sure that you don't create too many
threads. If a user sets it up for 250 MaxClients, they mean 250
MaxClients. All in all, I am convinced from reading the design that a
shared linked list is the wrong solution.
Ryan
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
