Jeff Trawick wrote:
>
> Ryan Bloom <[EMAIL PROTECTED]> 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.
>
I'll tweak threaded and worker to return "workers_may_exit" ASAP, and
wait for feedback on the naming.
> Anybody got a favorite name?
>
> ap_mpm_server_exiting() return non-zero if this process going away
I like this name best, but "server" bothers me some (someone might think
it refers to all of Apache). How about: ap_mpm_process_exiting()
(same return spec as above)
> ap_mpm_accepting_requests() return zero if this process going away
not bad either, but I think one of the "exiting" names gets the point
across more directly.
Greg
p.s. my apologies if I caused any confusion. I didn't realize there was
an existing callback directly into all the MPMs right where we need it.