On 2013-06-11 22:21, Alex Bligh wrote:
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;
}
The threadallocatormutex is created from a child of the request pool.
The request pool and its child-pools are destroyed when the request
terminates. Do you use the
threadpool/threadallocator/threadallocatormutex afterwards?
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.
