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 <[email protected]> To: William A. Rowe Jr. <[email protected]> Cc: [email protected]; [email protected] Sent: Thursday, April 18, 2013 2:57 AM Subject: Re: undefined reference to `apr_pool_mutex_set' "William A. Rowe Jr." <[email protected]> writes: > On Wed, 17 Apr 2013 15:14:31 +0000 (UTC) > Igor Galić <[email protected]> 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
