httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: Anywhere to go for a summmary of I/O filtering?
Date Tue, 25 Jul 2000 14:21:55 GMT
Tony Finch <> writes:

> Bill Stoddard <> wrote:
> Um, do you mean event-driven IO (select/poll/kevent) rather than async
> IO (aio_*,SIGIO)?
> I agree that offloading keepalive connections to a holding thread
> would be a win, and the bonus is it's something that can be done with
> minimal change outside the mpm.

Another relatively easy task would be to manage lingering close in a
similar manner.  I don't know how to assess the value of such a
change.  I would guess that not tying up any extra processes/threads
in lingering close would be of some benefit, though not nearly as much
as not tying up extra processes/threads waiting for the next request
(keepalive).  Once the infrastructure for select/read-for-keepalive is
in the MPM, lingering close is easy to handle with multiplexed I/O.

Drastically reducing the number of processes/threads in keepalive (and
lingering close to a much lesser extent) seems to have a very high
benefit-to-cost-ratio.  It shouldn't require any *serious* modifications
to Apache other than in the MPM.  Apache would of course need to be
able to return back to the MPM in keepalive state so that the MPM can
manage it.

The MPM work is somewhat interesting...

One thread within one process needs to poll for new connections in
addition to readability on connections that process owns and which are
in keepalive.  One thread in every other process needs to pool for
readability on connections that process owns and which are in
keepalive.  (And don't forget periodic time out processing for
connections in keepalive.)  This is a little different than today
where only one thread among all MPM threads/processes is in poll.  The
existing thread mutex decides which thread within a given process
proceeds towards poll.  A new problem to solve is how to arbitrate
which process waits on new connections in addition to work on
connections owned by that process.  One way to arbitrate this is to to
get the interprocess mutex in blocking mode if the process has no
other work and to attempt to get the interprocess mutex in
non-blocking mode if the process has other work to wait for.  (Greg
Ames and I discussed this enough a month or so ago to get some feeling
for the types of problems we would run into if starting from
mpmt_pthread or dexter.  Any stupid ideas above are definitely mine,
not Greg's.)

Jeff Trawick | | PGP public key at web site:
          Born in Roswell... married an alien...

View raw message