httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: [PATCH] Problems with MPM threaded
Date Sat, 14 Jul 2001 08:36:01 GMT
On Sat, Jul 14, 2001 at 01:06:28AM -0700, Aaron Bannert wrote:
> This looks like a job for condition variables. Using condition
> variables you can control exactly when threads get woken up to check
> on the condition.  For example, when one thread returns from accept(),
> it can signal another thread to move to the accept() state (and as an
> optimization that I think Ryan suggested, now you don't need to have
> an intraprocess accept lock, since only one thread can be listening in
> accept() at a time). The other threads are blocked waiting for some
> condition, either allowing them to pass to the accept() state or the
> workers_may_exit state.

The problem, as I see it, is that you are mixing an *interprocess* 
accept lock (otherwise, you'll have two processes call accept - no-no 
on some platforms - threaded MPM, as it stands, has *multiple* child
processes *each* consisting of threads) and an *intraprocess* 
destruction mechanism (workers_may_exit).  The issue here is that the 
accept_mutex may get passed onto another process which doesn't need to 
be destroyed (hence, it won't give up the mutex for a while - forcing 
the "doomed" child's threads to belay the request to die).

If condition variables allow you to handle this gracefully (the man 
page doesn't seem to indicate this mixing of scopes), then maybe that 
is a solution.  But, remember, if the mutex stays within one process,
everything is happy and fine.  

The "correct" fix, as I see it, is to kill off the interprocess 
accept lock by removing the possibility of having other processes
in a *threaded* MPM.  -- justin


Mime
View raw message