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 Wed, 24 Apr 2013 00:46:11 GMT
Hi Igor,

The patched APR library has been included in the UniMRCP dependencies package for many years
now. The latest version can be downloaded from the following link.

http://code.google.com/p/unimrcp/downloads/detail?name=unimrcp-deps-1.1.3.tar.gz


If you have any further question with regards to UniMRCP, I'd suggest we use the corresponding
Discussion Group.


Arsen



________________________________
 From: Igor Galić <i.galic@brainsware.org>
To: Arsen Chaloyan <achaloyan@yahoo.com> 
Cc: Philip Martin <philip@codematters.co.uk>; William A. Rowe Jr. <wrowe@rowe-clan.net>;
dev@apr.apache.org 
Sent: Monday, April 22, 2013 7:48 AM
Subject: Re: undefined reference to `apr_pool_mutex_set'
 


Hi Arsen,


the only problem with patching APR is that someone has to maintain that patch/package now.
The incentive for package distributors is rather low to add this patch to their standard set.

What's your deployment recommendation?

-- i

________________________________

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