apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject Re: Bucket management strategies for async MPMs?
Date Sun, 01 Sep 2002 00:56:20 GMT
Cliff Woolley wrote:

>On Sat, 31 Aug 2002, Brian Pane wrote:
>
>  
>
>>Wouldn't it be sufficient to guarantee that:
>> * each *bucket* can only be processed by one thread at a time, and
>> * allocating/freeing buckets is thread-safe?
>>    
>>
>
>No.  You'd need to also guarantee that all of the buckets sharing a
>private data structure (copies or splits of a single bucket) were, as a
>group, processed by only one thread at a time (and those buckets can exist
>across multiple brigades even).
>

I *think* this one can be solved by making the increment/decrement
of the bucket refcount atomic.

>You'd also have to guarantee that no
>buckets are added/removed from a given brigade by more than one thread at
>a time.
>

This part is easy to guarantee.  When the worker thread passes
buckets to the writer thread, it hands off a whole brigade at once,
so that ownership of the brigade passes from one thread to another.

>  When you add up the implications of all these things, it
>basically ends up with the whole request being in one thread at a time.
>  
>

If we can overcome this limitation, it will be straightforward
to build an async MPM.  If not, the fallback solution would be:

  * Each worker thread does its own network writes, up until the
    point where it sees EOS.
  * At that point, the worker thread hands the remaining brigade
    off to the writer thread.  (In doing so, it's basically transferring
    the entire request to the writer thread.)

This would give us the benefits of async writes for static files,
where the core_output_filter could immediately transfer the
response_header+file_bucket+EOS brigade to the writer thread and
let the worker thread go on to work on other requests.  For large
streamed responses, though, the worker would end up writing almost
the entire response.

Brian



Mime
View raw message