[vlc-devel] [RFC PATCH 2/3] decoder: merge locks and conds

Rémi Denis-Courmont remi at remlab.net
Wed Apr 1 17:00:56 CEST 2015


Le 2015-04-01 17:13, Thomas Guillem a écrit :
> ---
>  src/input/decoder.c | 148
> ++++++++++++++++++++++++++++------------------------
>  1 file changed, 79 insertions(+), 69 deletions(-)
>
> @@ -633,7 +634,7 @@ static bool DecoderWaitUnblock( decoder_t *p_dec 
> )
>              if( !p_owner->b_waiting || !p_owner->b_has_data )
>                  break;
>          }
> -        vlc_cond_wait( &p_owner->wait_request, &p_owner->lock );
> +        vlc_cond_wait( &p_owner->wait, &p_owner->lock );

So here you replace wait_request with wait. wait is thus used for the 
decoder thread to wait for the ES output.

>      }
>
>      return p_owner->b_flushing;
> @@ -718,7 +719,7 @@ static void DecoderWaitDate( decoder_t *p_dec,
>              break;
>          }
>      }
> -    while( vlc_cond_timedwait( &p_owner->wait_request, 
> &p_owner->lock,
> +    while( vlc_cond_timedwait( &p_owner->wait, &p_owner->lock,
>                                 i_deadline ) == 0 );

Ditto.

>  }
>
> @@ -737,7 +738,7 @@ static int DecoderPlaySout( decoder_t *p_dec,
> block_t *p_sout_block )
>      if( p_owner->b_waiting )
>      {
>          p_owner->b_has_data = true;
> -        vlc_cond_signal( &p_owner->wait_acknowledge );
> +        vlc_cond_signal( &p_owner->wait );

But here the decoder thread signals wait. This has no (useful) effects. 
I cannot say that one or the other code path is wrong, but the 
combination of both is illogical.

Ditto in many other left out snippets.

-- 
Rémi Denis-Courmont



More information about the vlc-devel mailing list