[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1033228 - in /subversion/branches/1.6.x: ./ CHANGES STATUS subversion/svnserve/main.c subversion/tests/cmdline/merge_tests.py

From: Blair Zajac <blair_at_orcaware.com>
Date: Wed, 10 Nov 2010 11:38:03 -0800

On 11/10/2010 10:34 AM, Philip Martin wrote:
> Blair Zajac<blair_at_orcaware.com> writes:
>
>>> + /* If we are using fulltext caches etc., we will allocate many large
>>> + chunks of memory of various sizes outside the cachde for those
>>> + fulltexts. Make sure, we use the memory wisely: use an allocator
>>> + that causes memory fragments to be given back to the OS early. */
>>> +
>>> + if (apr_allocator_create(&allocator))
>>> + return EXIT_FAILURE;
>>> +
>>> + apr_allocator_max_free_set(allocator, SVN_ALLOCATOR_RECOMMENDED_MAX_FREE);
>>> +
>>> /* Non-standard pool handling. The main thread never blocks to join
>>> the connection threads so it cannot clean up after each one. So
>>> separate pools, that can be cleared at thread exit, are used */
>>> - connection_pool = svn_pool_create(NULL);
>>> +
>>> + connection_pool = svn_pool_create_ex(NULL, allocator);
>>> + apr_allocator_owner_set(allocator, connection_pool);
>>
>>
>> Shouldn't the allocator have a mutex registered with it, given that
>> svnserve is multithreaded?
>
> No. I believe each thread gets its own allocator and pool, from which it
> creates subpools as required. When the thread exits it destroys the
> pool, which destroys the allocator since the pool has been set as the
> owner. So each allocator is only used by one thread.

Thanks Philip for looking into it and seeing that we're fine.

Blair
Received on 2010-11-10 20:38:45 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.