> "Bill Stoddard" <[EMAIL PROTECTED]> writes:
>
> > > -----
> > > > Jeff Trawick wrote:
> > > >
> > > > >Aaron Bannert <[EMAIL PROTECTED]> writes:
> > > > >
> > > > >>I appreciate that you are trying to moderate my usage of the -1 (veto),
> > > > >>but feel it is my duty to inform the list as soon as possible that I
> > > > >>wouldn't be happy with this big of a change.
> > > > >>
> > > > >
> > > > >Maybe a veto wasn't appropriate, but it seemed clear to me that a
> > > > >number of people would rather have the new code side by side with the
> > > > >old for a while, and Brian didn't seem disturbed about that notion at
> > > > >all.  Hopefully nobody will actually go remove worker as soon as
> > > > >Brian's code is committed :)
> > > > >
> > > >
> > > > I disagree.  Unless someone wants to volunteer to put a workaround
> > > > in the current worker code to fix the queue-full case, I can't
> > > > rationalize including it in another beta or GA release.  We need
> > > > to either fix it or remove it.
> > > >
> > > > --Brian
> > >
> > > I am in grudging agreement with Brian. I don't have a lot of time to spend on 
>this,
but
> > > I'll take a look at making worker behave more like mpm_winnt, which should fix 
>the
> > > problem.
> > >
> > > Bill
> >
> > Before anyone goes weird on me for that last comment, I am specifically referring 
>to
how
> > mpm_winnt manages the queue between the accept and worker threads.  Not planning on
> > changing anything else about how worker operates other than how the accept/worker
queue is
> > managed.
>
> I'll be interested in exactly what you want to change.

This basic problem is that you want to not allow the worker to accept more connections
that it has threads (ie, a worker should never have more than ThreadsPerChild active
connections).  One way of doing this is to use Brian's approach.  It is pretty invasive
though and would likely take a while to drive out the bugs. There are much easier
solutions.

The problem with worker is that fd_queue_elem_t's are recycled too quickly.  They 
should
not be added back to the queue (and made available to the accept thread) until the 
worker
thread dispatched by the element is finished with the connection. (mpm_winnt does this
correctly with a queue element called a "completion_context"). In mpm_winnt, the accept
thread does the equivalent of an ap_queue_pop to get queue element. If one is not
available, then the accept thread yields its time slice.  The workers do the 
equivalent of
an ap_queue_push at the end of handling a connection to make more queue elements
available.

Bill

Reply via email to