httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: plz vote on tagging current CVS as APACHE_2_0_19
Date Wed, 27 Jun 2001 01:26:03 GMT

> 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


Mime
View raw message