[vlc-devel] commit: Destroy the playlist AFTER looking for a sout attached to it ( Rafaël Carré )
rdenis at simphalempin.com
Mon May 19 17:50:25 CEST 2008
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.
More information about the vlc-devel