httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: ap_graceful_stop_signalled()
Date Thu, 02 Aug 2001 19:22:50 GMT
Ryan Bloom wrote:
> On Thursday 02 August 2001 10:24, Jeff Trawick wrote:

> >
> > 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. 

No.  First of all, it isn't the core, it's http.  Jeff, shame! shame!

Ryan, now you're referring to an obsolete name, not what needs to happen
here.  shame! shame! shame! ap_graceful_restart_signalled was an
appropriate name in 1.3 for a server which only did http, and used
signals all over the place to blow workers out of the water.  

Let's say the 1.3 folks had named the function
ap_should_http_keepalive_read_loop_exit()  That's the real question they
needed answered, and graceful restarts were the only case that wasn't
taken care of by signals.  The name they chose was easier to type, and
appropriate at the time.

> The MPM does not and should not control if any more requests
> are to be served.  That is up to the protocol itself.  

and, appropriately enough, http is the caller of the function in

>                                            Now, as far as the child process
> is concerned, every reason to shutdown gracefully can and should be handled the
> same way.

I agree that they should, but they aren't.  SIGWINCH/apachectl graceful
is allowed to exit the HTTP keepalive read loop, the rest can loop
> 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.

OK, no problem.  If that's the case, FTP and POP3 shouldn't call the
function that asks the MPM if it is trying to shut down the process.
I'll commit a change to worker and threaded to solve the HTTP infinite
loop problem, now that we understand that this won't hurt other
protocols.  It sounds like it will take longer to choose a better name
for the function.


View raw message