[vlc-devel] commit: The playlist is not lock at this stage so let it lock itself. ( Rémi Duraffort )

[Pierre d'Herbemont]

Quoting Rémi Denis-Courmont <rdenis at simphalempin.com>:

> Le jeudi 17 juillet 2008 20:22:20 Pierre d'Herbemont, vous avez écrit :
> > On Jul 17, 2008, at 6:50 PM, Rémi Duraffort wrote:
> > > Le jeudi 17 juillet 2008 à 06:43:40, git version control a écrit :
> > >> vlc | branch: master | Rémi Duraffort <ivoire at videolan.org> | Thu
> > >> Jul 17 17:58:33 2008 +0200|
> > >> [6cc9595de6e94e5f56242a7b605fc30fa3369081]
> > >>
> > >> The playlist is not lock at this stage so let it lock itself.
> > >
> > > The playlist locking is not my cup of tea so if someone can review
> > > it...
> >
> > I think it's ok, though I would have prefered if we had switched to
> > pl_Locked or pl_Unlocked. That's easier to read ;)
> >
> > I think I'll wait for Remi's return for that but playlist item
> > destruction is broken. It cannot work as we don't know who will access
> > the playlist_item. So accessing a playlist_item is safe only if the
> > playlist lock is held. But it is not what is done in practical cases.
> > So I guess we should remove playlist item deletion, and post pone them
> > at the very end of the playlist.
>
> I am not very intimate with the input item reference counting. But "deleting"
> a reference which you (potentially) do not own is always broken, if that's
> what you mean. VLC is full of such issues (that's why I had to remove the
> vout and aout recycling for the time being).

Well, this is a different topic ;)

I was speaking of the *playlist_item* issues. They are not refcounted. They are
supposed to never be accessed outside the playlist lock. After the playlist lock
is released you can't assume that your playlist_item is alive. The original
correct way to do it, seems to reference their id.

However, you'll realize soon that no one (qt4/osx) is doing it correctly, and we
are full of races there.

input_item refcounting is working pretty well.

Pierre.