On Sat, Mar 23, 2013 at 6:22 PM, Stefan Fritsch <s...@sfritsch.de> wrote: > On Saturday 23 March 2013, Jeff Trawick wrote: >> On Sat, Mar 23, 2013 at 12:01 PM, Stefan Fritsch <s...@sfritsch.de> > wrote: >> > On Saturday 16 March 2013, Jeff Trawick wrote: >> >> This would be good to resolve in 1.5.2. >> >> >> >> Has anyone else evaluated this? I'm suspicious of the use of a >> >> global pool in the reporter's patch vs. just using malloc() >> >> directly. I guess the reason for using the pool is that the >> >> allocator may have suitable buffers lying around, but you need >> >> one for the pool and one for the structure instead of just >> >> getting one from malloc(). I haven't tried any performance >> >> tests yet. >> > >> > An alternative would be using apr_allocator_alloc() directly >> > (with the global pool's allocator). Creating a sub-pool seems >> > more overhead than necessary. Not sure what is better, malloc() >> > or apr_allocator_alloc(). >> >> No good way to get to global_pool/global_allocator from outside >> apr_pools.c AFAICT >> >> I think malloc() wins here... > > You are right. What about > > http://svn.apache.org/r1460243
Looks good here... > > Anyone has a system using CRYPTD to test this? Not me (chuckle)... AIX anyone?
