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