[vlc-devel] commit: input: Remove p_playlist gc signaling now that the playlist is aware of vlc_InputSelectedStreamChanged . (Pierre d'Herbemont )

Pierre d'Herbemont pdherbemont at free.fr
Sun Jun 15 21:15:40 CEST 2008


On Jun 15, 2008, at 7:11 PM, Rémi Denis-Courmont wrote:

> As far as I can tell, there is absolutely no way to prevent this  
> unless we
> forbid holding any object which is not one's direct child. And if we  
> do that,
> reference counting is anyway useless, since there can only ever be  
> one entity
> holding any given object.


> Once libvlc has released an object, it has no way to know if the  
> object has
> been destroyed, or if it is still held by yet another object. So  
> LibVLC may
> endup reaching the "critical" late stages of instance clean up while  
> some
> objects/threads are still active. That's why we still have input  
> item leaks
> in fact.

All agreed.

Here is a playlist specific sketches of what we could do. We introduce  
vlc_object_wait_destruction(). (Hence we can still have some objects  
properly refcounted, but we can also make sure the object gets destroy  
when we think it's necessary.


Pierre.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-threads-Remove-the-pthread_detach-hack.patch
Type: application/octet-stream
Size: 1100 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20080615/e77976e7/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Make-sure-the-playlist-will-be-really-detroyed-at-li.patch
Type: application/octet-stream
Size: 4209 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20080615/e77976e7/attachment-0001.obj>


More information about the vlc-devel mailing list