> 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. > > Jonathan Rose wrote: > Ah, this is correct. I should have locked prior to setting the control > count.
Oh, that didn't work. Yeah, I had to do a countainer count check afterwards instead otherwise I'd be stuck waiting for commands to finish before I could queue more and that's wrong. - 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
