Stefan Fuhrmann wrote on Fri, Apr 13, 2012 at 15:55:18 +0200: > Am 13.04.2012 16:35, schrieb Daniel Shahaf: >> stef...@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.