[vlc-devel] Locking Issues (OS X)

[Pierre d'Herbemont]

On Mon, Dec 21, 2009 at 6:50 AM, Brian Weaver <cmdrclueless at gmail.com> wrote:
> I'm still trying to track down the menu problem that is haunting me in the current OS X code. I'm making progress and learning a bit about the underlying codebase at the same time. During my bug hunt I've run across something that I'm hoping someone with a deeper understanding can help me sort out.

ok.

> Part of the problem is an uneven amount of holding and releasing in the OS X client. I've started to get familiar with the vlc_object_hold() and vlc_object_release(). I've found out that playlist_CurrentItem() returns a vlc_object that has had vlc_hold_object() applied for the callers convenience.   These calls are mainly being applied to the main playlist object (p_input).

object_[hold/release] increment and decrement the internal structure
of the object, not the object itself. The notable exception is the
input_thread_t object, for which it ensure the full object life span.

> I've now discovered another (new?) locking scheme that is being applied to the same object. The two new locking API are vlc_gc_incref() and vlc_gc_decref(). I guess I'm confused on how the two different API interact with each other on the same object. I could really use some hints.


vlc_gc_incref applies to input_item_t element. It will increase or
decrease the reference count. They are not supposed to act on the same
object. However you'll find many places in vlc where input_item_t and
input_thread_t instances are named p_input. This can be confusing.

Pierre.