<!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 22:20, 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, 21.12.27 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 22:01, 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 keskiviikkona 29. maaliskuuta 2017, 20.45.59 EEST Filip Roséen a écrit </code></pre>
<p>:</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">
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> It fixes the issue described in ticket [#18151][1], which you closed
as
a
duplicate of [#17652][2]. I would be interested to see know how
#18151
is
not fixed, as I did extensive testing and a lot of proof-reading to
inspect the relevant paths taken.</code></pre>
</blockquote>
<pre><code> I would be interested to know how a lock inversion can be fixed while
not
settling for one lock order or the other, nor eliminating the code
paths
leading to either orders.</code></pre>
</blockquote>
<pre><code> As stated, you are the one who closed `#18151` as a duplicate of
`#17652`; the ticket description for the former in detail describe
what lock is being taken, and why it deadlocks.</code></pre>
</blockquote>
<pre><code> It is not strictly a duplicate but more of a specific instance of it. And
as ALREADY NOTED BEFORE, this is just removing one code path leading to
it.
I did warn Thomas that this was a playlist problem and not a preparser/
prefetcher problem quite a while back. If the whole point of this patch
series was to fix this bug, then it seems that you missed the point and
unfortunately wasted your time.</code></pre>
</blockquote>
<pre><code> I do not believe that I have wasted my time, as such it has not been a
waste of time (as what constitutes as "waste of time" is highly
subjective); you are of course entitled to your own opinion.
Once again, I am very interested in knowledge related to how the
issue described by `#18151` is reproducible after the relevant set of
patches.</code></pre>
</blockquote>
<pre><code> Given you insist on not explaining, I´m going to assume that this means that I
am right and this is not fixing the bug.
18151 is a THEORETICAL bug. You fix it by giving a THEORETICAL PROOF that it
is fixed, in other words, by enforcing a consistent lock order.</code></pre>
</blockquote>
<p>Since when it is theoretical? Please create a directory containing some content, then open up that directory with VLC (such as specifying it on the command line), and magically that “theoretical” issue will turn into a practical one.</p>
<p>I honestly cannot see how you can even consider it to be theoretical when it is <strong>really</strong> easy to reproduce by following the ticket description.</p>
</body>
</html>