I think if you always wait until a command has been executed before you send a new command, it can't happened that you stop the wrong playback. If you pass Event-UUID in sendmsg like

…
sendmsg
Event-UUID: 5bf340cd-7a7e-4965-9285-95ed365ed242
call-command: ...
execute-app-name: ...
execute-app-arg: ...
…


you will get this UUID back as Application-UUID in the CHANNEL_EXECUTE and CHANNEL_EXECUTE_COMPLETE events, so we are able to match it. 

So you can wait until you get CHANNEL_EXECUTE_COMPLETE before you send your second playback.

See also "Correlate SendMsg reply with request in async mode" in the mailing list.

- Markus


Am 31.05.2013 um 16:38 schrieb D D <tru083@yahoo.com>:

Hi,

If I have an async ESL playback operation running, and I issue a 'break', immediately followed
by a new playback, is there any chance that the second playback will be stopped by the 'break' ?

In my testing I never observed something like this happening, but I was wondering if event-lock 
is really needed in this case.  The event-lock causes other side effects that I would
like to avoid if possible.

Thanks,
David

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org