> 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?
A timing window. When a mod_status request is the last request accepted before a
process
dies. Yea, this is an edge case and maybe we shouldn't care. That is my opinion, but
generally tradeoffs like this don't wash with the group :-)
>
> 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.)
I would definitely like to decouple the portion of the scoreboard used to track status
from the portion used for child process management.
Bill
