apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Botond Botyanszki <b...@siliconium.net>
Subject pools vs thread safety
Date Fri, 27 Jan 2012 11:43:37 GMT

After debugging with valgrind, it looks like I have some pool related race
condition in my multithreaded apr code where I have a thread-pool with
multiple workers. Files and sockets are passed to the worker threads for
As far as I understand apr_palloc and apr_pool_destory can not be called
from different threads.
Now my problem is that the socket and file API relies on pools, i.e.
I see no way to create sockets/files without the use of apr_pools. 

I was trying to debug my code with APR_POOL_DEBUG set to pool owner
check. This results in an abort as soon as the file/socket is passed to a
worker thread. The documentation suggests the use of
apr_pool_owner_set(), but I have not found this anywhere, except in this patch: 

I didn't try this yet, though lets suppose I put apr_pool_owner_set() in
my code to places where there is no concurrent access to pool allocated
resources but only thread ownership change, and then it turns out that it
detects a real pool related race condition bug somewhere.
Then if I cannot rewrite the code, what other options are there?
I found this patch which adds thread safe pools:
This looks to be one possible solution, though the problem is that I will
be able to ship my program only with this patched apr statically linked
Other solution would be to use dedicated mutex locks in the code for
each shared pool, but this feels a little awkward. If files/sockets could
be created with malloc instead, this issue would be a lot easier to solve.

Any hints or suggestions how others tackled this kind of problem?
Thanks in advance.


View raw message