[vlc-devel] vlc: svn commit r22812 (funman)

Rafaël Carré funman at videolan.org
Tue Oct 23 15:18:24 CEST 2007

Hash: SHA1

Rémi Denis-Courmont a écrit :
> On Tue, 23 Oct 2007 14:10:31 +0200 (CEST), Subversion daemon
> <svn at videolan.org> wrote:
>> r22812 | funman | 2007-10-23 14:10:30 +0200 (Tue, 23 Oct 2007) | 4 lines
>> Changed paths:
>>    M /trunk/modules/control/dbus.c
>> dbus: don't lock the playlist, but only yield the input to prevent its
>> destruction while we are accessing it.
>> We do that because we can't lock the playlist when we're in the input
>> "state" callback because we MAY have been called by playlist_Control(),
>> which does lock the playlist, and then call us.
>> ref #1346
> I don't quite understand that one.
> Why:
> 0/ get input from playlist
> ...
> 1/ vlc_object_yield(input)
> 2/ var_Get(input)
> 3/ vlc_object_release(input) ???
> If the input cannot be destroyed between 0 and 1, why could it get
> destroyed between 1 and 3? And, if it can be destroyed between 0
> and 1, then you are screwed - vlc_object_yield will crash instead
> of var_Get.

Well, looking a bit better at the problem, if I'm in a input_thread_t*
callback, I can safely assume that the input will not be destroyed, and
so I don't need to lock the playlist, right ?

I can see this code in the beginning of __var_Set():

    vlc_object_internals_t *p_priv = p_this->p_internals;
    vlc_mutex_lock( &p_priv->var_lock );

If that is true, then I'll correct the code.

Your comments are the most valuable documentation I can get except the
source code itself.
Since I sometimes feel uncomfortable with locking code, should I ask on
this mailing list before making potentially wrong commits, or is the
commit log enough ?
I'd go for the 1st, but I feel bad when I'm not answered, don't know if
nobody has a clue / nobody cares / my question is too dumb.

- --
Rafaël Carré
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the vlc-devel mailing list