[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 4:48 PM, Rémi Denis-Courmont wrote:

> Le Monday 19 May 2008 14:49:46 Pierre d'Herbemont, vous avez écrit :
>> That makes me think, its probably a pity to have implemented such a
>> work around in core (remove children, and then call destructor). We
>> need an other solution.
>
> It's a choice, not a work-around.

Yeah, right.

> On a high-level, IMHO, there are basically three possible choices:
>
> 1) The thread "owning" (typically that which created) the object  
> must detach
> any children before it releases the object.
>
> 2) Children are automatically detached when the object is destroyed.
>
> 3) A child counts as a reference (either implicit or explicit), such  
> that
> destruction is only performed when (i_children + i_refcount) == 0.  
> Then
> yielding an object with no reference (but still some children)  
> becomes legal.
>
> We are currently doing 1. We used to have 2. I really don't care  
> what we use,
> and I'm OK with changing it once more so long as we stick to it.

You meant we used to do 2, and now we do 1? (Else, I am lost).

> Note that only 3 ensures warrants that an attached children can  
> always use its
> parent until detached. I am not sure if it would introduce new  
> deadlocks.

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.

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.

I think we could stay as-is for now, but as everything tends to be  
broken, it's probably time to re-design and fix.

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

Pierre.