----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3379/#review11404 -----------------------------------------------------------
/branches/12/res/ari/resource_bridges.c <https://reviewboard.asterisk.org/r/3379/#comment21062> 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. /branches/12/res/ari/resource_bridges.c <https://reviewboard.asterisk.org/r/3379/#comment21064> 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. /branches/12/res/res_stasis.c <https://reviewboard.asterisk.org/r/3379/#comment21049> I'm going to temporarily play the Josh Colp role here and claim that the RAII_VAR and SCOPED_AO2LOCK are a bit over-the-top for this function. - Mark Michelson On March 25, 2014, 10: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, 10: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
