Re: [xine-devel] Xine 1.1.0 thread bug wont't xine_stop

[Barry S. <bar...@on...>]

Miguel Freitas wrote:

>On 11/15/05, Michael Roitzsch <mr...@us...> wrote:
>  
>
>>Wouldn't it be even clearer in the code, if the information of
>>ignore_speed_change could be carried by the lock itself? I mean:
>>* get rid of the integer variable altogether
>>* use only the speed_change_lock
>>* stream->ignore_speed_change = 1 is replaced with locking
>>* stream->ignore_speed_change = 0 is replaced with unlocking
>>* _x_set_fine_speed() uses
>>    if (pthread_mutex_trylock(&stream->speed_change_lock) == 0) {
>>      /* do speed change */
>>      pthread_mutex_unlock(&stream->speed_change_lock);
>>    }
>>    return;
>>    
>>
>
>yes, it looks clearer to me.
>
>Miguel
>
>  
>
Your proposal is not the same as my patch in one case, but I don't know
if this case happends in xine.

If _x_set_fine_speed is used on more then one thread it should not
consider the lock being held as the need to ignore the speed change.
Only when xine_stop sets ignore_speed_change must the other threads
no longer set the speed.

So long as only one other thread ever calls _x_set_fine_speed your
patch should work. I'm very busy on another problem at the moment
so I'm not sure when I could test out your proposal.

Are you in a position to test your proposal? If not could you go with
my patch until I can test your idea out?

Barry