<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta name="generator" content="pandoc" />
<title></title>
<style type="text/css">code{white-space: pre;}</style>
</head>
<body>
<p>Hi Rémi,</p>
<p>On 2017-03-29 21:21, Rémi Denis-Courmont wrote:</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> Le keskiviikkona 29. maaliskuuta 2017, 19.36.32 EEST Filip Roséen a écrit :</code></pre>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> Hi Rémi,
On 2017-03-29 20:30, Rémi Denis-Courmont wrote:</code></pre>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> Le perjantaina 24. maaliskuuta 2017, 3.28.29 EEST Filip Roséen a écrit :</code></pre>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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).</code></pre>
</blockquote>
<pre><code> That sounds very prone to deadlock and therefore a bad idea. (Though you
could argue that cancel itself is the bad idea.)</code></pre>
</blockquote>
<pre><code> 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).</code></pre>
</blockquote>
<pre><code> 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.</code></pre>
</blockquote>
<p>Please elaborate on how such deadlock would occur.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> For instance, you can´t ensure that another thread won´t request preparsing
between cancel and playback.</code></pre>
</blockquote>
<p>Which is a separate issue, and please note that <code>#17232</code> (again by intention) explicitly states what that ticket is about.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> Not to mention LibVLC ought to have the same problem and does not use the
playlist, and it´s unclear what happens then.</code></pre>
</blockquote>
<p>The same problem with duplicate entries in the playlist without using the playlist?</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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).</code></pre>
</blockquote>
</blockquote>
<p>Best Regards,<br />
Filip</p>
</body>
</html>