httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@ebuilt.com>
Subject Re: [PATCH] Problems with MPM threaded
Date Sat, 14 Jul 2001 08:06:28 GMT
On Sat, Jul 14, 2001 at 12:42:29AM -0400, GUMMALAM,MOHAN (HP-Cupertino,ex2) wrote:
[snip]
> SOLUTION 1:  I plan to temporarily implement a new
> apr_lock_acquire_timeout() function, which would cause the threads waiting
> on the mutex to give-up after sometime.  The piece of code would look
> something like this:
> 
> while ((rv = SAFE_ACCEPT(apr_lock_acquire_timeout(accept_mutex, timevalue)))
> 	!= APR_SUCCESS) {
> 	if (check_if_timer_popped)
> 		if (workers_may_exit)
> 			break;
> 	else {                         /* apr_lock_acquire failed */
> 		ap_log_error(....);
> 		workers_may_exit = 1;
> 	}
> }
> 
> I know that this would cause some performance impact, but my guess is that
> it would not be a lot, especially if we keep the timevalue reasonably high.
> However, in order to get the functionality of
> perform_idle_server_maintenance() working right, we _will_ have to implement
> the above solution (or maybe something similar)!


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.

If this sounds like something you could use here, I can probably elaborate
on this some more, maybe even give some [pseudo]code.

-aaron


Mime
View raw message