[vlc-devel] [PATCH 2/7] playlist/preparser: refactor

[Filip Roséen]

Hi Rémi,

On 2017-03-29 21:21, Rémi Denis-Courmont wrote:

> 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.

Please elaborate on how such deadlock would occur.

> For instance, you can´t ensure that another thread won´t request preparsing 
> between cancel and playback.

Which is a separate issue, and please note that `#17232` (again by
intention) explicitly states what that ticket is about.

> Not to mention LibVLC ought to have the same problem and does not use the 
> playlist, and it´s unclear what happens then.

The same problem with duplicate entries in the playlist without using
the playlist?

> > 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).

Best Regards,\
Filip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20170329/11503f4e/attachment.html>