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

[Rémi Denis-Courmont]

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.

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

This may be very error-prone too.

(...)
> For now that would mean find who calls FIND_CHILD from destructor, as
> this cannot work now, and returns an empty list.

There are not that many destructors at the moment. If it happens, it should be 
trivial to find.

-- 
Rémi Denis-Courmont
http://www.remlab.net/