apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: bug 54572 -- move struct crypt_data allocation to heap
Date Sat, 23 Mar 2013 23:04:27 GMT
On Sat, Mar 23, 2013 at 6:22 PM, Stefan Fritsch <sf@sfritsch.de> wrote:
> On Saturday 23 March 2013, Jeff Trawick wrote:
>> On Sat, Mar 23, 2013 at 12:01 PM, Stefan Fritsch <sf@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?

Mime
View raw message