[vlc-devel] commit: Implement access_GetParentInput and demux_GetParentInput and use. ( Pierre d'Herbemont )
pdherbemont at gmail.com
Wed Aug 26 22:27:10 CEST 2009
On Aug 26, 2009, at 9:32 PM, Laurent Aimar wrote:
> On Wed, Aug 26, 2009, Pierre d'Herbemont wrote:
>> On Aug 26, 2009, at 8:01 PM, Rémi Denis-Courmont wrote:
>>>> Are we not supposed to do that? Fine, but don't let it compile
>>> How do you know that the caller is right or wrong?
>> Just don't allow vlc_object_hold() on it. Then you are safe. Or make
> Nope, on correctly written object, you can call var_Set* on a
> but you cannot arbitrary call any accessors. For that you need to look
> at the docs when present, and if not documented, assume you cannot.
Okay, that was clear.
My point is we don't do proper refcounting on some object that
Your point is that we've never been annoucing more than only
refcounting internals so that variables can be used.
To me vlc_variables shouldn't exists at all, but that's an other
So obviously there is something missing: The documentation on that, or
the name changes in the API, to be less misleading.
We don't do proper refcounting for (all?) vlc_object_t, even if we
pretend we do by having this vlc_object_hold. (This used to be even
more true back in the time when we used to wait until object
So to change that, we could do something like:
#define vlc_object_hold(a) __vlc_object_hold(VLC_OBJECT(a));
vlc_object_t * __vlc_object_hold_variables(vlc_object_t *)
void vlc_object_release(vlc_object_t *);
And even probably remove completely vlc_object_hold() from public API?
#define vlc_object_hold(a) __vlc_object_hold(VLC_OBJECT(a))
vlc_object_t * __vlc_object_hold(vlc_object_t *)
#define vlc_object_release(a) __vlc_object_release(VLC_OBJECT(a))
void __vlc_object_release(vlc_object_t *)
<object_name>_hold() on objects that can actually be retained in the
sense that you really own a reference to it (Laurent's type 3).
More information about the vlc-devel