[vlc-devel] [PATCH 28/33] chromecast: make sure we send the load when the data are flowing

[Hugo Beauzée-Luyssen]

On 12/23/2015 12:58 PM, Steve Lhomme wrote:
> ---
>   modules/stream_out/chromecast/chromecast_ctrl.cpp | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/modules/stream_out/chromecast/chromecast_ctrl.cpp b/modules/stream_out/chromecast/chromecast_ctrl.cpp
> index ae2a1a0..d8a759a 100644
> --- a/modules/stream_out/chromecast/chromecast_ctrl.cpp
> +++ b/modules/stream_out/chromecast/chromecast_ctrl.cpp
> @@ -299,8 +299,8 @@ void intf_sys_t::processMessage(const castchannel::CastMessage &msg)
>                   if (!appTransportId.empty()
>                           && getConnectionStatus() == CHROMECAST_AUTHENTICATED)
>                   {
> -                    setConnectionStatus(CHROMECAST_APP_STARTED);
>                       msgConnect(appTransportId);
> +                    setConnectionStatus(CHROMECAST_APP_STARTED);
>                       msgPlayerLoad();
>                       setConnectionStatus(CHROMECAST_MEDIA_LOAD_SENT);
>                       vlc_cond_signal(&loadCommandCond);
>
Again, this is not related to your commit, but this block seems dubious, 
since it's being executed with the intf_sys_t::lock held, meaning the 
thread awaiting for the wait cond broadcast issued from 
setConnectionStatus will be signaled, but will hold waiting for the mutex.
So you get the wait cond signaled twice (plus a 3rd time with a direct 
vlc_cond_signal call).
The last 2 signals are noops since the thread isn't waiting on the wait 
condition anymore, and I'd argue that it feels strange to have the wait 
cond signaled with both broadcast & signal.