apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Galić <i.ga...@brainsware.org>
Subject Re: undefined reference to `apr_pool_mutex_set'
Date Mon, 22 Apr 2013 14:48:29 GMT
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 

----- Original Message -----

> 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