On Fri, Nov 25, 2016, at 10:20 AM, Dennis Guse wrote: > Hey guys, > > we continued working on our largest changeset: https://gerrit. > asterisk.org/#/c/3524/ > Besides the copyright of HRTFs (still under investigation from our side), > the only issue on our side is the introduced `settings_lock` (defined in > bridge.h:254). > This lock is used in addition to the bridge-lock in bridge_softmix:1093. > > The issue the settings_lock solves is that during bridge startup > (actually > `softmix_mixing_thread()`) we need to know the configuration parameters > (is > binaural active or not?). > Since the startup of the mixing thread and parsing the configuration is > asynchronous (at least our understanding: we saw race conditions), we use > the 2nd lock to wait until configuration information is available before > really starting the mixing thread. > We could avoid introducing the settings_lock by repeatedly checking in > the > mixing loop. > However, this doesn't sound like a good idea... > Thus, a bridge now has two locks (ast_bridge_lock and the settings_lock), > which is some overengineering. > > Is there a better solution to addressing this issue?
While I don't yet have an answer for this I've poked others and am pondering options myself. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
