[vlc-devel] commit: Destroy the playlist AFTER looking for a sout attached to it ( Rafaël Carré )
pdherbemont at free.fr
Mon May 19 18:47:42 CEST 2008
On May 19, 2008, at 5:50 PM, Rémi Denis-Courmont wrote:
> Le Monday 19 May 2008 18:15:50 Pierre d'Herbemont, vous avez écrit :
>> There is also 4, that you also did purpose some time:
>> 4) Attached objects gets their refcount increased by one. When
>> detached their refcount is decreased by one, after calling the
>> destructor. That allows to remove most of the destructors work, which
>> is currently badly done, and fix FIND_CHILD from destructor. But it
>> would also introduce some new bugs, such as detach+attach, that would
>> need a yield/release.
> As far as the objects core is concerned, that's all the same as 3.
> The only
> difference is that you invoke the destruction callback earlier than
> internal object destruction.
It doesn't seem to be the same.
If you own:
p_obj (refcount = 1+2)
vlc_object_release( p_obj ) -> you can never reach the destructor.
If you want the refcount to reach 0, you have to call something like
vlc_release_children( p_obj ). So basically, this solve our problem by
expecting the object owners to explicitely know when the object
refcount reaches i_children, and explicitely release children
accordingly. This seems a bit flawed, regarding to the advantages of
>> I think 3- cannot work easily. It means that you can never destroy an
>> object if you don't release the children. That means you have to now
>> about object internals if you want to release it. Probably it's
>> probably too much overhead.
> Sure. But 4 has the opposite problem: Children will find their
> parents even
> after these have been "half-destroyed". That is to say, the type-
> properties (anything beyond VLC_COMMON_MEMBERS) will have been
> destroyed by
> the parent pf_destructor, even though the "base" object will still
> be there.
Sure. Yet, children don't have to release their parents, whereas the
contrary is true.
Also, we don't have to return an half-destroyed object.
By the way, I really think that we are fine as we are. We just need to
remove that hierarchy :)
More information about the vlc-devel