Brian Pane wrote: > I'm willing to spend some time this week on this issue, but first, can > somebody clarify how prefork is handling the pipe-of-death? > > It looks like prefork children only check the pod upon completion of > a request. Is that all there is to it, or am I missing something?
There has to be a way to unblock accept()s when a graceful restart happens in order to get rid of the apr_poll. I think prefork depends on the logic in mpm_common.c::ap_mpm_pod_[signal|killpg] that sends dummy connects to do this in situations where there's low/no traffic from the network. (disclaimer: haven't studied the code recently) btw, some of the workers_may_exit checks may not be necessary any more, so we might be able to eliminate some conditional branches in the mainline path. The threaded MPM had the possibility of workers_may_exit getting set asynchronously on thread x, and apparently we wanted thread y to know ASAP. (same disclaimer) Greg
