This really belongs in dev@apr... Adding it now. If we are *really* drastically changing this core aspect of pool allocation, we should reconsider my thoughts related to more granular mutex related to anytime we alloc from a pool to allow for, if required/desired, full thread safety not just when creating a subpool or destroying.
> On Mar 3, 2017, at 2:38 PM, Yann Ylavic <ylavic....@gmail.com> wrote: > > First fix :) > > On Fri, Mar 3, 2017 at 6:41 PM, Yann Ylavic <ylavic....@gmail.com> wrote: >> >> With apr_allocator_bulk_alloc(), one can request several apr_memnode_t >> of a fixed (optional) or minimal given size, and in the worst case get >> a single one (allocaœted), or in the best case as much free ones as >> available (within a maximal size, also given). > > The non-fixed version was buggy (couldn't reuse lower indexes), so > "apr_allocators-bulk-v2.patch" attached. > Will post some numbers (w.r.t. buffers' resuse and writev sizes) soon. > <apr_allocators-bulk-v2.patch>
