[vlc-devel] [PATCH] Playlists, Dbus
polar.humenn at gmail.com
Fri Nov 21 16:37:44 CET 2008
Sorry, I screwed up the Subject again. I'm still getting used to Gmail.
On Fri, Nov 21, 2008 at 10:35 AM, Polar Humenn <polar.humenn at gmail.com> wrote:
> 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
> 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
> 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.
>> vlc-devel mailing list
>> vlc-devel at videolan.org
>> End of vlc-devel Digest, Vol 18, Issue 104
More information about the vlc-devel