Sorin,
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.
Thanks.
> 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 && pool
)) {
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
