[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