apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arsen Chaloyan <achalo...@yahoo.com>
Subject Re: undefined reference to `apr_pool_mutex_set'
Date Thu, 18 Apr 2013 18:23:58 GMT
Hello Igor, William and Philip,

As the author of the piece of software Igor was referring to, I'd add a few comments regarding
the use of the APR memory pools in the UniMRCP project.

First of all, when I just started using the APR library I had an impression that operations
on memory pools are thread-safe. That was obviously my oversight. Facing this problem, I had
no choice but to patch the APR memory pools, since memory allocations are done indirectly
inside the APR lib at least in some places. In fact, the patch was initially borrowed from
another project, FreeSWITCH, which seemed to encounter the same problem. Later, I came across
similar patches in other projects too and now I'm not sure where this patch came from originally.
Perhaps this doesn't really matter at this point.


I personally didn't bring this up to the APR group, since the patch didn't address general
use, and from what I could see, the APR maintainers seemed to be opposed adding support for
thread-safe memory pools. I understand all the concerns regarding concurrent use of memory
pools and don't encourage that either, but having such an option seems commonsensical to me.


Now, why the patch makes perfect sense for the UniMRCP project but cannot be considered for
general use. I use an event driven architecture with a fixed number of threads/tasks created
upon initialization of MRCP client or server stacks. A new memory pool is created for each
MRCP session. The majority of other objects created in the scope of that session are allocated
from the same session pool. The pool might be concurrently used by sub-tasks/threads. Although
the probability of the concurrent use is very low, it still does exist. Eventually, when the
session and its associated memory pool are getting destroyed, it's guaranteed that these objects
are not referenced from any other place, in other words, there are no dangling references.
This routine is implemented internally, out of the APR scope. Theoretically, I could relatively
easily avoid the concurrent use of memory pools by creating a sub-pool for each sub-task/thread,
but this would have a clear
 downside too such as memory usage (unnecessary creation of a new memory block of 4/8k for
each pool).

I'm certainly not very happy having APR patched but at the same time I realize this is something
I should live with.

http://www.unimrcp.org/dependencies/apr-1.4.6.patch


Thanks for your attention!
-- 
Arsen Chaloyan
Author of UniMRCP
http://www.unimrcp.org



________________________________
 From: Philip Martin <philip@codematters.co.uk>
To: William A. Rowe Jr. <wrowe@rowe-clan.net> 
Cc: dev@apr.apache.org; i.galic@brainsware.org 
Sent: Thursday, April 18, 2013 2:57 AM
Subject: Re: undefined reference to `apr_pool_mutex_set'
 

"William A. Rowe Jr." <wrowe@rowe-clan.net> writes:

> On Wed, 17 Apr 2013 15:14:31 +0000 (UTC)
> Igor Galić <i.galic@brainsware.org> wrote:
>> 
>> caused by this projects creative use of APR:
>> https://code.google.com/p/unimrcp/issues/detail?id=29
>> 
>> Is there anything I can do other than compile a sepcial version of
>> APR for this project's requirements?
>
> That's what happens when projects don't push hacks upstream :(
> Sorry we can't provide too much guidance.  If there is a submitted
> patch under the AL lying around somewhere, please flag it to the 
> dev@ list for consideration.

The patch adds a mutex to apr_pool_t and locks the mutex in calls to
apr_palloc, apr_pool_clear and apr_pool_destroy.  That may make those
individual calls threadsafe but it doesn't really make pool use as a
whole threadsafe.  If one thread clears a pool every other thread using
the pool is left with dangling references.  It looks like a lot of
locking for no real gain.

-- 
Philip
Mime
View raw message