On 22 Jun 2015, at 10: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. The secret to all of this is the pool hierarchy - if a request is to be served by any thread in a pool of threads, then that request mustn’t ever contain memory allocated from a pool tied to a specific thread. When mod_proxy learned how to do connection pooling there were subtle pool lifetime issues uncovered caused by the backend connections allocated from a connection pool being interfaced to the frontend connections per request. You have to get the pools 100% right. Regards, Graham —
