httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@remulak.net>
Subject Re: [PATCH] Threaded MPM and unserialized accept
Date Mon, 16 Jul 2001 19:42:21 GMT
Justin Erenkrantz wrote:
> 
> On Mon, Jul 16, 2001 at 02:24:28PM -0400, Greg Ames wrote:
> > eh?  why not?  Works fine on OS/390; I suspect it works fine on recent
> > Linux kernels too.
> 
> Please read the earlier threads (it's long and confusing though).

I did, and I was (confused, that is).  But thanks, this helps...

> In short: we can't have all of the threads in a process waiting for
> the accept (blocking call).  Why? 

If you don't have all the idle workers waiting on accept on a platform
with S_L_U_A, it seems sub-optimal due to extra syscalls in the main
path.

> Consider the POD.  One thread receives the connect that occurs with the
> POD, reads the POD, sets workers_may_exit, and exits.  Now, on machines
> with S_L_U_A, all of the other threads are now in the blocking accept
> (on machines without S_L_U_A, they are in a cross-process mutex
> acquire).  They will never wake up until they receive a connection (or
> get the mutex).  This won't happen on a fairly-idle server for a long
> time - even though we want to die.  Hence, you need to serialize all
> of the worker threads in a process using something similar to the
> patch I submitted.  -- justin

I'll take a closer look at your patch, now that I understand what you're
trying to fix.  But if you're mutexing the accepts within a process for
the S_L_U_A case, I'd really like to find an alternative design.  Like
hitting the threads with more dummy connects when the process needs to
go away, for example.

We still don't have a good way to kill threads that are busy serving
.iso's when a non-graceful restart or shutdown happens.

Greg

Mime
View raw message