[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 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  
> the
> internal object destruction.

It doesn't seem to be the same.

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.

>> 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- 
> specific
> 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 :)

Pierre.