[vlc-devel] commit: Implement access_GetParentInput and demux_GetParentInput and use. ( Pierre d'Herbemont )
remi at remlab.net
Wed Aug 26 20:01:32 CEST 2009
Le mercredi 26 août 2009 20:24:11 Pierre d'Herbemont, vous avez écrit :
> So if we do a:
> 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
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.
More information about the vlc-devel