httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <c...@force-elite.com>
Subject Re: async write completion prototype
Date Mon, 10 Oct 2005 07:01:16 GMT
Brian Pane wrote:
> With the batch of commits I did this weekend, the Event MPM in
> the async-dev Subversion branch now does write completion
> in a nonblocking manner.  Once an entire response has been
> generated and passed to the output filter chain, the MPM's
> poller/listener thread watches the connection for writability
> events.  When the connection becomes writable, the poller
> thread sends it to one of the worker threads, which writes
> some more output.

If the content has already been generated, why add the overhead of the 
context switch/sending to another thread?  Can't the same event thread 
do a non-blocking write?

Once it finishes writing, then yes, we do require a context-switch to 
another thread to do logging/cleanup.

I am mostly thinking about downloading a 1 gig file with the current 
pattern against a slow client.  A non-blocking write might only do ~64k 
at a time, and causing 1 gig/64k context switches, which seems less than 
optimal.

...
> - The main pollset in the Event MPM currently is sized to
>   hold up to one socket descriptor per worker thread.  With
>   asynchronous keepalives and write completion, the pollset
>   should accommodate many descriptors per thread.

The pollset is auto-resizable.  That number is just the maximum number 
of events that will ever be returned by a single call to _poll().  This 
number if perfect for the number of threads, since we can never dispatch 
to more than the number of threads we have...

> - The scoreboard probably needs a redesign.

Yes.. it is completely unhelpful with the maximum number of connections 
being > number of threads. I suspect going forward there will be many 
other areas where this assumption is broken by the event mpm.

-Paul


Mime
View raw message