At 05:42 PM 06/26/2001, Bill Stoddard wrote:
>>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.
Why would any of these processes still be serving new
requests? Wouldn't they have been killed off during the
restart? They'd only still be around if they were serving old
requests, those that came in before the restart. The mod_status
request would have to go to one of the new processes.
Am I missing something here?
If this is the case, then this sounds like a good argument for
decoupling mod_status from the scoreboard format, and using the hooks
that were discussed here recently. (I think they were implemented,
but I'm not sure.)
--
Greg Marr
[EMAIL PROTECTED]
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"
