httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: [PATCH] convert worker MPM to leader/followers design
Date Thu, 11 Apr 2002 19:20:06 GMT
"Bill Stoddard" <bill@wstoddard.com> writes:

> > Right, the problem is that the listener needs to avoid doing the
> > accept if the queue is full.
> >
> > That part is easy: add a "block_if_queue_full()" method on the
> > fd_queue class, and have the listener call it before doing an
> > accept.
> >
> 
> I am not an expert on the worker MPM but I don't think that is an accurate statement
of
> the problem.  The accept thread uses ap_queue_push() to enqueue a socket for the worker
> threads. ap_queue_push() will block if the queue is full.
> 
> The problem is that the queue can be EMPTY even when all the worker threads are busy
> handling connections.  The way the code is today, the queue can hold ap_threads_per_child
> elements. Now consider 2 x ap_threads_per_child connections comming into the server at
> once.. The first 1 x ap_threads_per_child connections will be accepted and handled by
the
> worker threads. The next ap_threads_per_child connections will get queued and this is
> precisely the problem...

That is the problem I thought was being dealt with originally...
After seeing it stated differently a couple of times I figured I was confused.

probably-stupid idea: 

Maybe a counter of blocked threads can be cheaply maintained within the
existing serialization.  The listener can use this to decide if it
should call accept() or give up the CPU.

But this bites

1) when there is just one child process (wasted syscall)

2) because it would normally go faster if the listener could stay just
   ahead of the workers so that workers can dequeue new work when they
   finish with the old without having to wait on the listener to
   enqueue something

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Mime
View raw message