On Thu, May 9, 2013 at 6:32 PM, Philip Martin <philip.mar...@wandisco.com> wrote: > Philip Martin <philip.mar...@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
