On Thu, Jul 19, 2001 at 01:32:01PM -0400, Greg Ames wrote:
> The PoD is working correctly, since graceful restart and
> perform_idle_server_maintenance are both working.
The current PoD code in CVS does not work correctly on systems that
require the acquisition of the cross-process accept_mutex (either
multiple listeners or non-S_L_U_A). When you have multiple child
processes, it'd take too long for all of the other threads to notice
the worker_may_exit flag.
There are two possible solutions as I have outlined before:
- Adding back in a worker_accept_mutex which serializes the worker
threads so that only one may block when acquiring the accept mutex.
This seems to be the original behavior as Ryan and Manoj intended.
But, we now negate S_L_U_A except across processes which is silly to
do for a threaded MPM.
- Another possible way to deal with this is to move the accept mutex
down to the smallest possible point (i.e. right before accept() call).
All threads will know when the POD arrives via poll(). They will
then check the POD (with a mutex there - possible we could get
around this?). It'll then check the w_m_e flag and exit if one of its
sibling threads received the POD. If w_m_e is set to 0, it will try
to acquire the accept mutex (via the new apr_lock_tryacquire) and if
it fails, it'll go back to poll. Otherwise, it'll continue. But,
this potentially leads to a thundering herd problem. The spmt MPM I
posted has this logic.
> Yeah, we have bugs to fix and improvements to make. But there are folks
> out there who need threaded and want a beta/binaries. As I recall,
> there were enough bugs with threaded in 2.0.16 so that I wouldn't
> recommend it to anybody who can only deal with binaries.
I wouldn't recommend using the threaded code at all because we are still
doing a per-process allocation mutex which causes threaded to become
useless. When that is changed (i.e. we enable SMS), I think that
threaded MPM will deserve to be beat up and tested. -- justin
