[vlc-devel] commit: Destroy the playlist AFTER looking for a sout attached to it ( Rafaël Carré )
pdherbemont at free.fr
Mon May 19 19:44:43 CEST 2008
On May 19, 2008, at 7:07 PM, Rémi Denis-Courmont wrote:
> Le Monday 19 May 2008 19:47:42 Pierre d'Herbemont, vous avez écrit :
>> 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
>> 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
> Actually, I wonder how 4 would work at all.
I was speaking of 3-, not 4.
> What if another thread yields the
> object back to i_refcount > i_children before all children are
When the refcount reaches 0 you can't yield it back. (I don't see why
we are talking about i_children here).
> You could end up running the destructor multiple times - not good.
> In fact, this
> is precisely what's going to happen if a children does FIND_PARENT.
No, FIND_PARENT shouldn't yield() the object back if the refcount
> Or I don't understand what you're trying to do.
I was just saying:
vlc_object_attach( p_parent, p_child )
vlc_object_yield( p_child )
vlc_object_destroy( p_parent )
vlc_object_detach( p_child )
vlc_object_release( p_child )
So, that we don't have to manually track the object. However that
solves nothing. It was just a proposition.
Though I really think that 3- doesn't work, for the arguments I was
>> By the way, I really think that we are fine as we are. We just need
>> remove that hierarchy :)
> We still need the hierarchy for variables inheritance, AFAIK.
More information about the vlc-devel