Hi, 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 processing. 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: http://mail-archives.apache.org/mod_mbox/apr-dev/200307.mbox/raw/%3c3f0da25b.4020...@cs.ucr.edu%3e 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: https://issues.apache.org/bugzilla/show_bug.cgi?id=51392 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 in. 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. Regards, Botond
