"Bill Stoddard" <[EMAIL PROTECTED]> writes:
> > A few other benefits to Pauls design:
> > 1. Eliminates the requirement for compiled in HARD_SERVER_LIMIT or
>HARD_THREAD_LIMIT.
>
> I retract this statement. You -can- get rid of HARD_*_LIMIT iff you don;t mind
>mod_status
> missing some thread status from time to time (which I doubt is acceptable). Consider
>the
> case where the admin increases either thread or server limit then does a restart.
>The
> scoreboard MUST grow. And the growth will -not- be visible to the old (before the
> restart) processes. If a mod_status request comes in and is handled by one of the
>old
> processes, it cannot report status of any of the threads that are writing status to
>the
> extended (new) portion of the scoreboard. I just don't see any way around this.
So if the last request processed by a worker in the old generation
is mod_status then it won't show status on the new generation. So
what? There is a timing window inherent in graceful restart for what
status can be displayed anyway (or what configuration is used in
general for that matter). Whether or not the new generation is
displayed *properly* is dependent upon when the request arrives
regardless of the scoreboard design. Having the request arrive
milliseconds later or earlier can show a different set of workers;
again, this is regardless of the scoreboard design.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
