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ć <[email protected]> To: Arsen Chaloyan <[email protected]> Cc: Philip Martin <[email protected]>; William A. Rowe Jr. <[email protected]>; [email protected] 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 <[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 > > >
