httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Bligh <>
Subject Re: thread safety and mpm-prefork
Date Tue, 11 Jun 2013 20:21:10 GMT

On 11 Jun 2013, at 21:10, Sorin Manolache wrote:

> apr_* and mpm_prefork are different software packages and ubuntu distributes them separately.
So it is almost certain that you have a thread-enabled libapr (i.e. compiled with APR_HAS_THREADS).
You would not be able to compile the code that uses apr_thread_create if your libapr was not
compiled with thread support.
> mpm_prefork is like any ordinary client of libapr. Just that it does not use the threading
functionality in libapr. So it cannot disable/optimise out the mutexes in libapr.


> Please be aware that apr_pools are not thread-safe. Only the creation of subpools is
thread-safe. So you should create a subpool per thread to stay safe.

I'm doing that. In fact I'm doing:

    if (!( ( apr_pool_create(&pool, r->pool) == APR_SUCCESS) &&
           ( apr_thread_mutex_create(&threadallocatormutex, APR_THREAD_MUTEX_UNNESTED,
pool) == APR_SUCCESS) &&
           ( apr_allocator_create(&threadallocator) == APR_SUCCESS) &&
           ( apr_allocator_mutex_set(threadallocator, threadallocatormutex), 1 ) &&
           ( apr_pool_create_ex(&threadpool, NULL, NULL, threadallocator) == APR_SUCCESS)
&& /* WARNING: pool has no parent\
           threadpool && threadallocator && threadallocatormutex &&
            )) {
	ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
                      "tcp_proxy_on_connect could not allocate pool");
        return NULL;

i.e. a subpool, then a new mutex, allocator, and parentless pool using the forgoing. I suspect
this is well into the land of overkill.

I'm doing similar with creation of bucket brigades. The issue seems to be linked to bucket
brigade processing (which is unsurprising as that's what's written to by one thread but read
by the other).

Any help (paid if necessary) welcome. It's an apache licensed tcp proxy module.

Alex Bligh

View raw message