Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Sender: trawick@rdu26-58-158.nc.rr.com
To: new-httpd@apache.org, rbb@covalent.net
Subject: Re: ap_graceful_stop_signalled()
References: <m3r8uwg6xe.fsf@rdu66-58-158.nc.rr.com>
	<3B6820DB.BEFBB810@remulak.net> <0108012033570F.05155@koj.rkbloom.net>
From: Jeff Trawick <trawick@attglobal.net>
Date: 02 Aug 2001 13:24:32 -0400
In-Reply-To: <0108012033570F.05155@koj.rkbloom.net>
Message-ID: <m3n15i4bov.fsf@rdu26-58-158.nc.rr.com>
Lines: 30
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Ryan Bloom <rbb@covalent.net> 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().

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

?????
-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...