httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Covener <cove...@gmail.com>
Subject Re: buckets across threads - question
Date Mon, 22 Jun 2015 11:20:09 GMT
On Mon, Jun 22, 2015 at 4:07 AM, Stefan Eissing
<stefan.eissing@greenbytes.de> wrote:
> Sort answer: no.
> Re issue 28: I will look into this more today. I was able to generate a segfault on connection
shutdown on Friday and work on a fix.
>
> Longer version re buckets:
> - even though buckets for a request are created inside a single worker thread, they are
mutated/split/placed on free list upon processing down the main connection. Which then all
affects their bucket_alloc_t from several threads. Especially on longer response bodies,
> - since there are no function pointers for bucket_alloc_t, it is not obvious to me how
one would replace them with another implementation.
> - what can be added are, of course, new bucket implementations. Maybe there is an approach
to move the data itself without copying more than once. With a clever handling of file buckets,
maybe no copying at all.
>
> Otherwise, I am open to ideas.

I am afraid the change will not fix #28. In the backtrace for #28 an
EOR bucket is being deleted while the buckets in a brigade are being
copied to a new pool. That triggers all of the end of request
processing way too early.

I was naively thinking as a POC it would be possible to pmemdup the
conn_rec and create a new bucket allocator (when you create the faux
request_rec) If it worked, we'd want to find some way to get the same
result in the core.  If we continue to share one at the real
connection level, I think it needs an option of a mutex under h2.

-- 
Eric Covener
covener@gmail.com

Mime
View raw message