[vlc-devel] [PATCH 2/7] playlist/preparser: refactor
Rémi Denis-Courmont
remi at remlab.net
Wed Mar 29 20:21:22 CEST 2017
Le keskiviikkona 29. maaliskuuta 2017, 19.36.32 EEST Filip Roséen a écrit :
> Hi Rémi,
>
> On 2017-03-29 20:30, Rémi Denis-Courmont wrote:
> > Le perjantaina 24. maaliskuuta 2017, 3.28.29 EEST Filip Roséen a écrit :
> > > This refactoring should not only allow for easier maintenance as the
> > > code size has shrunk, it also implements a few advantages over the
> > >
> > > previous implementation:
> > > - playlist_preparser_Cancel is now optionally blocking if the
> > >
> > > referred to item is currently being preparsed (required in cases
> > > where another action would race with the preparser, such as
> > > playback (as preparsing and playing an entity at the same time can
> > > lead to duplicate items in the playlist).
> >
> > That sounds very prone to deadlock and therefore a bad idea. (Though you
> > could argue that cancel itself is the bad idea.)
>
> The cancellation is required in order for us to not run into issues
> where we preparse and entity while it is requested for playback,
> potentially resulting in duplicate entries in the playlist (as
> described by #17232).
That does not sound right. If you do it that way, you will almost certainly
end up with races, leading either #17232 again, or to a deadlock.
For instance, you can´t ensure that another thread won´t request preparsing
between cancel and playback.
Not to mention LibVLC ought to have the same problem and does not use the
playlist, and it´s unclear what happens then.
> The mechanism could, of course, be renamed to
> `playlist_preparser_DeleteFromQueueOrWaitForFinish` (though something
> better, though I cannot come up with a good name right now).
--
雷米‧德尼-库尔蒙
https://www.remlab.net/
More information about the vlc-devel
mailing list