httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject [PATCH] Threaded MPM and unserialized accept
Date Sun, 15 Jul 2001 06:00:36 GMT
Is this just an oversight?  NO_SERIALIZED_ACCEPT is never defined
anywhere.  I'm beginning to wonder how maintained threaded MPM is.  =)

Now the question becomes with my other patch for adding the
worker_accept_mutex - what to do on platforms that have
SINGLE_LISTEN_UNSERIALIZED_ACCEPT?  Their accept call does not
suffer from the "thundering herd" problem, BUT we can't have multiple
workers in the same process sitting in the accept call either.  (What 
we earlier had as cross-process mutex has now shifted to kernel-level 

We need to be able to wake up all of our sibling threads in a 
decent manner.  So, we're back to the same problem discussed earlier
- we need a worker_accept_mutex intraprocess mutex.  This negates the
usefulness of the unserialized accept.  Again, only one worker per 
child process can ever try to be in the accept() call, or else 
we're going to have problems when that process receives a POD.
(Each thread will be in accept() and won't exit until they've 
received a connection.)

Thoughts?  -- justin

Index: server/mpm/threaded/threaded.c
RCS file: /home/cvs/httpd-2.0/server/mpm/threaded/threaded.c,v
retrieving revision 1.44
diff -u -r1.44 threaded.c
--- server/mpm/threaded/threaded.c	2001/07/03 13:58:10	1.44
+++ server/mpm/threaded/threaded.c	2001/07/15 05:43:45
@@ -183,7 +183,7 @@
 static apr_lockmech_e_np accept_lock_mech = APR_LOCK_DEFAULT;
 static const char *lock_fname;
 #define SAFE_ACCEPT(stmt) (stmt)

View raw message