apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gunter Coelle <gunter.coe...@dbaudio.com>
Subject Re: [PATCH]: alternative implementation apr_hash_first()
Date Wed, 30 Apr 2003 08:24:58 GMT
Mladen Turk wrote:

>  
>
>>-----Original Message-----
>>    
>>
>>Ok, lets try again:
>>Purpose of this patch:
>>apr_hash_first allocates memory for the iterator struct on 
>>every call (if p!=NULL), before jumping to the first entry of 
>>the table. In applications, where a thread iterates through 
>>the table permanently (using apr_hash_first() + 
>>apr_hash_next()) this will create memory shortage in the 
>>longer run and also slows down the iteration due to repeating 
>>allocations. This patch is a proposal of separating the 
>>allocation of an iterator and jumping to the first record 
>>into two different functions.
>>
>>    
>>
>
>I have the same problem using iterator in the threaded environments, and
>perhaps it would be beter just to make the apr_hash_index_t as public
>struct.
>That's how I did it, and it suits for me. Further more this aproach need
>not to change the existing code.
>
>MT.
>
>  
>
You're right, it would also be the better alternative.
I already did this as a fix in my apps and other hashtable
implementations are mostly using this technique too.
But I'm not sure of the apr-'policy'. AFAIK public structs are
avoided wherever possible in the headers.

Gu


Mime
View raw message