[vlc-devel] vlc-devel Digest, Vol 18, Issue 104

[Polar Humenn]

Laurent Aimar <fenrir at via.ecp.fr> writes:

>> @@ -517,10 +523,12 @@ int playlist_PlayItem( playlist_t *p_playlist, playlist_item_t *p_item )
>>      set_current_status_item( p_playlist, p_item );
>>
>>      pl_priv(p_playlist)->status.i_status = PLAYLIST_RUNNING;
>> -
>> +
>> +    PL_UNLOCK;
>>      var_SetInteger( p_playlist, "activity", i_activity +
>>                      DEFAULT_INPUT_ACTIVITY );
>> -
>> +    PL_LOCK;
>> +
>  I really fear that they will create race conditions. You allow someone to lock
> the playlist in the middle of a command...
>
>  Is the playlist deadlocking itself or a module ?

Yes.   The Dbus module locks up, because Open adds Callbacks which get
triggered when an item is added to the playlist, which calls
TrackListChangeEdit function. The only problem is that you do NOT have
a guarantee on the lock of the play list whenever this callback may be
called.

The idea of unlocking before any callback is called, gives us a clear
defined semantics with which to operate, so that we always "do the
right thing" when designing, programming, and adding playlist variable
callbacks.

Now, I see where this particular situation above may be a problem. But
the real questions should be asked:

1. Why is the "activity" variable set at this point in the code?

2. What would put a callback on the "activity" variable?

Maybe the "activity" variable should be set, and the potential
callbacks executed, should be set later at the end of the call. For
instance, at the end of the call where "playlist-current" is set.

Cheers,
-Polar



> --
> fenrir
>
>
>
> ------------------------------
>
> _______________________________________________
> vlc-devel mailing list
> vlc-devel at videolan.org
> http://mailman.videolan.org/listinfo/vlc-devel
>
>
> End of vlc-devel Digest, Vol 18, Issue 104
> ******************************************
>