httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: ap_graceful_stop_signalled()
Date Thu, 02 Aug 2001 17:51:44 GMT
On Thursday 02 August 2001 10:24, Jeff Trawick wrote:
> Ryan Bloom <> writes:
> > Wait a second, I'm confused.  Jeff, if I read your message correctly, you
> > are saying that you want to remove the ap_graceful_stop_signalled()
> > function with an ap_mpm_query call.  You don't want to add any new
> > functionality, just change how we determine what is going on.
> ...
> > As for changing the function, -0.5.  I don't care if we change the name
> > of the function, but this kind of thing doesn't belong in the
> > ap_mpm_query function. That function should be used to query information
> > about the MPM, and the current configuration.  It should not be used to
> > track the state of the MPM.
> The core needs to ask the MPM whether or not another request should be
> accepted on the connection.  This is a little more general than the
> purpose of ap_graceful_stop_signalled().

I disagree with that.  The core is asking if the child is exiting gracefully.  That is
all it is asking.  The MPM does not and should not control if any more requests
are to be served.  That is up to the protocol itself.  Now, as far as the child process
is concerned, every reason to shutdown gracefully can and should be handled the
same way.

I can easily imagine some protocols that want to continue serving requests, even if
the server is restarting, think FTP or POP3.  But some, want to cut off the client after
a given number of requests, such as HTTP.

> We can rename ap_graceful_stop_signalled() to something more
> appropriate and also tweak the internals to reflect other reasons why
> core shouldn't accept another request.
> Anybody got a favorite name?
>   ap_mpm_server_exiting()       return non-zero if this process going away
>   ap_mpm_accepting_requests()   return zero if this process going away

I disagree with this.  See above.


Ryan Bloom               
Covalent Technologies

View raw message