More thoughts... On Fri, Mar 20, 2015 at 12:00 PM, Yann Ylavic <ylavic....@gmail.com> wrote: > > While pool (allocator) allocations are not thread-safe, creating a > subpool is, and each thread can than use its own pool (this model is > often used with APR pools). > > This tells nothing about pool allocated objects' lifetime though > (accross/after threads), so maybe can you describe a bit more (but > less than the code ;) which object has its own or shared pool, with > regard to http/2 model (request/stream/connection/frame)?
When a subpool is destroyed, it is also recycled by the allocator for further use, and it can also be cleared-then-recycled explicitly (hand made, with locking). It shouldn't be an issue to create a (sub)pool per http/2 entity (request/stream/connection/frame), the lifetime can even be controlled/terminated by special (apr_)buckets (destructors), which when sent through the filters and handled by the last (core) filter, will be cleared (eg. in httpd, when the request is finished, an EOR bucket is sent to output filters and will destroy the request once (not before!) it is fully forwarded, or an error occured (thus the final brigade containing the special bucket is destroyed, explicitly or with its pool, and so is the bucket). With this model, it's "just" a matter of that entity belongs to that other one (destroyed with it, and possibly cleared-than-recycled in the meantime for special needs). Can't that feet to http/2 model?
