[vlc-devel] commit: Implement access_GetParentInput and demux_GetParentInput and use. ( Pierre d'Herbemont )

[Rémi Denis-Courmont]

Le mercredi 26 août 2009 20:24:11 Pierre d'Herbemont, vous avez écrit :
> So if we do a:
> vlc_object_hold(p_demux)
> and then one of the owner (the main one?) gets to delete this object.
> demux_IsPathExtension() will crash.

Blame whoever's calling demux_IsPathExtension() from the wrong thread.

> Are we not supposed to do that? Fine, but don't let it compile without
> warning.

How do you know that the caller is right or wrong? If you have solved the 
halting problem, I'm all ears.

>   So, if they don't need to be refcounted and doesn't support
> refcounting, vlc_object_hold() should be disabled on those objects then.

The private data does not support reference counting. It is completely 
impossible. We need to attach an object *before* we run module_need() on it, 
so that variables can be propagated in pf_open. At the same time, as soon as 
an object is attached, it becomes visible from vlc_object_find(), 
vlc_object_find_name() and vlc_list_children().

So evidently, anything that pf_open initializes or modifies is outside the 
scope of reference counting. From access_t, p_module, p_sys, pf_control, 
pf_read, p_block, psz_access, psz_path and info are all in that case for 
instance. Besides, we really don't want to make all object callbacks re-
entrant. It would be too complicated, error-prone and inefficient.

This was already discussed several times, e.g. during the DBus plugin fiasco 
when calling access_t.pf_control asynchronously.

> Either you have:
> - one owner and no refcounting.

That's what we have for almost all object type-specific data. audio_mixer_t is 
one of very few specially designed exceptions.

> - multiple owner and a way to interrupt the service (The so called
> Delete), in this case you have to ensure that accessors will not
> crash, or will return something coherent.

That's what we have for most of the vlc_object_t common data, including the 
object type name (constant) the libvlc pointer (constant), the logging 
parameters, the VLC object variables, the children list...

> > A destructor is only useful when you have some type-specific data to
> > be
> > accessed through the object tree. Then you need to destroy it only
> > when the
> > reference count drops to zero. Most types don't, so a type-specific
> > destroy
> > function is sufficient, which is called by the "owner" of the object.
>
> They are multiple owners when you do refcounting.

I stay by my statement that pf_destructor is almost completely useless. It's 
only useful for those few object types with type-specific thread-safe data.

VLC variables are -by far- the most common of object references, and do not 
need a custom destructor.

-- 
Rémi Denis-Courmont
http://www.remlab.net/