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.
-- Stefan^2.
