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

Re: Thread issues in svnserve

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Thu, 9 May 2013 19:14:06 +0400

On Thu, May 9, 2013 at 6:32 PM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Philip Martin <philip.martin_at_wandisco.com> writes:
>
>> It might be better to pass iterpool instead of connection_pool into
>> apr_thread_create. The problem with tattr also applies to memory
>> allocated by apr_thread_create such as *new. At present *new is not
>> accessed after the thread has started but the implementation could
>> change. So new patch:
>
> No, that won't work. It's not possible to clear/destroy the pool passed
> to apr_thread_create until the thread has started (so that dummy_worker
> can access the memory) and there is no guarantee that will have happened
> when apr_thread_create returns.
>
> That makes pool handling a bit tricky. We can't use connection_pool
> because that goes wrong when the thread completes too quickly, and we
> can't use a subpool because that goes wrong when the thread starts too
> slowly.
>
Yes, that's problem.

But currently APR doesn't access apr_threadattr_t from worker thread
and doesn't need access to apr_thread_t from main thread. So using
iterpool for apr_threadattr_t and connection_pool for apr_thread_t
fixes problem, but only with current APR implementation. That's why I
call my fix workaround and didn't commit it to trunk.

> Perhaps we have to look at the httpd code?
>
httpd doesn't create worker thread dynamically, so they can allocate
apr_thread_t in global pool. Also it has dedicated win32 mpm that uses
CreateThread Windows API directly.

-- 
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Received on 2013-05-09 17:14:58 CEST

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