[vlc-devel] commit: Destroy the playlist AFTER looking for a sout attached to it ( Rafaël Carré )

[Pierre d'Herbemont]

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)
>> 	p_child1
>> 	p_child2
>>
>> 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
>> refcounting.
>
> 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  
> detached?

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  
reaches zero.

> Or I don't understand what you're trying to do.

Probably :)

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  
explaining before.

>> By the way, I really think that we are fine as we are. We just need  
>> to
>> remove that hierarchy :)
>
> We still need the hierarchy for variables inheritance, AFAIK.

Probably.

Pierre.