httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: [PATCH] convert worker MPM to leader/followers design
Date Thu, 11 Apr 2002 17:25:18 GMT


> "Bill Stoddard" <bill@wstoddard.com> writes:
>
> > > -----
> > > > Jeff Trawick wrote:
> > > >
> > > > >Aaron Bannert <aaron@clove.org> 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


Mime
View raw message