> On March 27, 2014, 5:14 p.m., Mark Michelson wrote: > > /branches/12/res/ari/resource_bridges.c, lines 502-508 > > <https://reviewboard.asterisk.org/r/3379/diff/4/?file=56650#file56650line502> > > > > A few things here. > > > > First and foremost, this isn't guaranteed to work. Consider that > > stasis_app_control_execute_until_exhausted() is running in thread 1 and > > ari_bridges_play_found() is running in thread 2. > > > > Thread 1 calls control_dispatch_all(), which returns 0. > > Thread 2 acquires the control lock. > > Thread 1 attempts to acquire the control lock but it cannot since > > thread 2 has the control lock held. > > Thread 2 checks if the control is done. It is not, so it decides to > > attempt the playback. > > Thread 2 unlocks the control lock. > > Thread 1 locks the control lock, sees that the command queue was > > exhausted, marks the control as done, and breaks from its loop. > > > > The result is that the queued playfile from thread 2 does not execute > > because thread 1 has already decided that its command queue is exhausted > > and has broken free from its loop. > > > > I think the best way to get around this is going to be to alter > > stasis_app_control_execute_until_exhausted() so that after it acquires the > > control lock, it checks the container count of the control's command_queue > > to see if something new has been added. If so, then continue instead of > > breaking. > > > > The other problem here is that I don't think that if the control is > > determined to be dying that a 500 response should be returned. Instead, you > > should fall back to the ari_bridges_play_new() behavior.
Ah, this is correct. I should have locked prior to setting the control count. > On March 27, 2014, 5:14 p.m., Mark Michelson wrote: > > /branches/12/res/ari/resource_bridges.c, lines 323-329 > > <https://reviewboard.asterisk.org/r/3379/diff/4/?file=56650#file56650line323> > > > > ari_bridges_play_found() calls this with the control locked, but > > ari_bridges_play_new() calls this with the control not locked. I suspect > > you do not want the lock held during this. > > Mark Michelson wrote: > Actually, after looking further, you probably *do* mean to have the lock > held when called from ari_bridges_play_found(). I still think it should be > consistent though. The reason I don't need the control locked in ari_bridges_play_new is because it hasn't been linked into the control list at that point, so only one thread can be touching it. There's no need for locking the control object until after it's put into the global list with stasis_app_bridge_playback_channel_add. I suppose I can lock it anyway and add a note that it should be locked when calling the helper function. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3379/#review11404 ----------------------------------------------------------- On March 25, 2014, 5:14 p.m., Jonathan Rose wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3379/ > ----------------------------------------------------------- > > (Updated March 25, 2014, 5:14 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-22677 > https://issues.asterisk.org/jira/browse/ASTERISK-22677 > > > Repository: Asterisk > > > Description > ------- > > Previously, if you played an audio file and then played another before the > first finished, the second audio file would start playing immediately as it > was called overlapping the previous sound. Apparently people don't like that. > This patch changes that behavior so that the sound will be queued at the end > of any existing controls if they are running. > > > Diffs > ----- > > /branches/12/rest-api/api-docs/bridges.json 411187 > /branches/12/res/stasis/control.c 411187 > /branches/12/res/stasis/control.h 411187 > /branches/12/res/res_stasis_playback.c 411187 > /branches/12/res/res_stasis.c 411187 > /branches/12/res/res_ari_bridges.c 411187 > /branches/12/res/ari/resource_bridges.c 411187 > /branches/12/res/ari/resource_bridges.h 411187 > /branches/12/include/asterisk/stasis_app.h 411187 > > Diff: https://reviewboard.asterisk.org/r/3379/diff/ > > > Testing > ------- > > Tested for playback channel wrapper leaks, tested to make sure control > objects were being destroyed when they fell out of use. Tested playing of a > single file. Tested playing of multiple files in a row. Tested playing of > multiple files in a row and then after a sequence finished, playing > additional files so that new channels would have to be created. Tested > playing sounds right as other sounds were concluding. I wasn't able to break > it (although I wouldn't be surprised if there is a possible condition where > you can grab a control as it is finishing up its queue and then attempting to > add a sound to a finished queue causing the playback to fail. I don't think > this would break things in a profound way, it just might possibly make one > sound fail to queue under extremely unlikely conditions). > > > Thanks, > > Jonathan Rose > >
-- _____________________________________________________________________ -- 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
