Stefan Fuhrmann wrote on Fri, Apr 13, 2012 at 15:55:18 +0200:
> Am 13.04.2012 16:35, schrieb Daniel Shahaf:
>> stefan2_at_apache.org wrote on Thu, Apr 12, 2012 at 20:02:37 -0000:
>>> Author: stefan2
>>> Date: Thu Apr 12 20:02:36 2012
>>> New Revision: 1325478
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1325478&view=rev
>>> Log:
>>> Introduce a new API function to create and initialize a new
>>> APR pool allocator. Make its thread-safety properties
>>> explicit in the docstring.
>>>
>>> Will be used by the next commit to replace boilerplate code.
>>>
>>> * subversion/include/svn_pools.h
>>> (svn_pool_create_allocator): declare new API function
>>> * subversion/libsvn_subr/pool.c
>>> (svn_pool_create_allocator): declare new API function
>>>
>>> Modified:
>>> subversion/trunk/subversion/include/svn_pools.h
>>> subversion/trunk/subversion/libsvn_subr/pool.c
>>>
>>> Modified: subversion/trunk/subversion/include/svn_pools.h
>>> URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/include/svn_pools.h?rev=1325478&r1=1325477&r2=1325478&view=diff
>>> ==============================================================================
>>> --- subversion/trunk/subversion/include/svn_pools.h (original)
>>> +++ subversion/trunk/subversion/include/svn_pools.h Thu Apr 12 20:02:36 2012
>>> @@ -30,7 +30,7 @@
>>> #ifndef SVN_POOLS_H
>>> #define SVN_POOLS_H
>>>
>>> -#include<apr_pools.h>
>>> +#include "svn_types.h"
>>>
>>> #ifdef __cplusplus
>>> extern "C" {
>>> @@ -86,6 +86,23 @@ svn_pool_create_ex_debug(pool, allocator
>>> */
>>> #define svn_pool_destroy apr_pool_destroy
>>>
>>> +/** Return a new allocator. This function limits the unused memory in the
>>> + * new allocator to @ref SVN_ALLOCATOR_RECOMMENDED_MAX_FREE and ensures
>>> + * proper synchronization if the allocator is used by multiple threads.
>>> + *
>>> + * If your application uses multiple threads, creating a separate allocator
>>> + * for each of these threads may not be feasible. Set the @a thread_safe
>>> + * parameter to @c TRUE in that case. Pools will still not thread-safe, i.e.
>>> + * access to them may require explicit serialization. Set the parameter to
>>> + * @c FALSE, otherwise, to maximize performance.
>>> + *
>>> + * To access the owner pool, which can also serve as the root pool for your
>>> + * sub-pools, call @c apr_allocator_get_owner().
>>> + *
>>> + * @since: New in 1.8
>>> + */
>>> +apr_allocator_t *
>>> +svn_pool_create_allocator(svn_boolean_t thread_safe);
>> Should this be an svn-private API? Should it take a parameter
>> that allows overriding the SVN_ALLOCATOR_RECOMMENDED_MAX_FREE default?
>>
> Not too long ago, I spent a couple of days hunting
> memory corruptions. The reason turned out to be
> the allocator not being thread-safe by default while
> the default allocator was.
>
> I think this interface is useful for people writing SVN
> clients and should therefore be public. The max free
> memory parameter can be modified at any time via
> apr_allocator_max_free_set() and it is rarely necessary.
> So, I would prefer a simpler API in that case.
>
Fair enough, thanks.
> -- Stefan^2.
Received on 2012-04-13 18:02:40 CEST