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 <[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
