[vlc-devel] commit: input: Remove p_playlist gc signaling now that the playlist is aware of vlc_InputSelectedStreamChanged . (Pierre d'Herbemont )
rdenis at simphalempin.com
Sun Jun 15 17:47:10 CEST 2008
Le dimanche 15 juin 2008 15:55:04 Pierre d'Herbemont, vous avez écrit :
> > You just
> > cannot destroy the playlist until the directory plugin has not
> > completed
> > reading its directory (which is a set of non-blocking operations).
> Actually it doesn't work, and you'll end up in leaking some input
> item, if you kill libvlc during directory processing. I am not sure
> about why.
What's the point of using object reference counting if you cannot hold objects
anyway??? Besides, the playlist is supposed to wait for the input to
terminate, which is supposed to wait for the demux to terminate. If you
intend to have a strictly hierarchical objects handling, then references
really are useless.
Of course, there is a problem with the circular holding pattern, even if it is
time-bound. If an "owner" releases an object while that object is held by its
own child, when the child release the object, it accidentally destroys its
parent. That's why you've added the pthread_detach hack. Unfortunately, if
the "owner" happens to be libvlc, from libvlc_destroy(), then you may destroy
critical core resources such as the playlist (which causes an assertion with
the playlist_item reference checks), or worse, the messages bank, the modules
bank, and finally the threads and objects subsystem (these will cause
The real problem here, is that merging vlc_object_release and
vlc_object_destroy was a bad idea. The "owner" of an object should not rely
on vlc_object_release, it should call vlc_object_destroy, which should _wait_
until all references are gone. To put it another way, the pthread_detach()
hack cannot ever work properly.
More information about the vlc-devel