----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3450/#review11620 -----------------------------------------------------------
I know I was thinking that this would be necessary everywhere; it may still be. However, when I wrote that particular bug report, we were still having crashes with reference counting issues in the main Stasis application loop. Your previous commits fixed that. While I dislike our current mechanism of tracking the bridge, I also don't want to make the reference counting issue more confusing than it already is. Is this patch still necessary? Do we feel that there are situations when a control structure has a pointer to a bridge but the bridge has been disposed of by some one else? - Matt Jordan On April 15, 2014, 4:09 p.m., opticron wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3450/ > ----------------------------------------------------------- > > (Updated April 15, 2014, 4:09 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-23588 > https://issues.asterisk.org/jira/browse/ASTERISK-23588 > > > Repository: Asterisk > > > Description > ------- > > This patch ensures that the Stasis control structure holds a reference to the > bridge the channel is in so that the pointer does not become stale. This also > introduces a new function for use cases that only need to check that the > channel is in a bridge and have no need for the bridge itself since > stasis_app_get_bridge now bumps the bridge's refcount when returning it. > > > Diffs > ----- > > branches/12/res/stasis/control.c 412426 > branches/12/res/res_stasis_recording.c 412426 > branches/12/res/res_stasis.c 412426 > branches/12/res/ari/resource_bridges.c 412426 > branches/12/include/asterisk/stasis_app.h 412426 > > Diff: https://reviewboard.asterisk.org/r/3450/diff/ > > > Testing > ------- > > > Thanks, > > opticron > >
-- _____________________________________________________________________ -- 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
