[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