On Mon, Jun 22, 2015 at 4:07 AM, Stefan Eissing <stefan.eiss...@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 cove...@gmail.com
