[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