<!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>On 2017-03-29 22:03, 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, 20.50.50 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">
<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 thread is per definition not waiting for the conditiona variable
at that time, so I cannot see how it would wake itself up.</code></pre>
</blockquote>
<pre><code> You are making unwarranted assumptions about condition variables here.</code></pre>
</blockquote>
<pre><code> Assumptions based on specifications, I would however be extremely
interested on implimentations where this "assumption" does not hold
(mostly because a issue should definitely be filed based on such
finding).</code></pre>
</blockquote>
<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> Been there done that.</code></pre>
</blockquote>
<pre><code> Previous paragraph.</code></pre>
</blockquote>
<pre><code> There is not much point in discussing if we cannot agree on facts such as the
meaning of the specification.</code></pre>
</blockquote>
<p>Opinion acknowledged.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> Both my experience and my understanding of CV tells me that this patch is
factually wrong.</code></pre>
</blockquote>
<p>Given that you say that my assumptions are wrong, the code should be easy to break, or there should be a very easy way to demonstrate that my assumptions about <em>condition-variables</em> are wrong.</p>
<p>I am happy to take a conforming implementation of the specification as an example, so if you could be kind to link me the source of such I would happily read it.</p>
<p>If my assumptions are wrong, I will be the first to say that I have been wrong, but I cannot do that without knowing what it is that is wrong, and why it is wrong.</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">
<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> Also it´s highly questionable that more than one thread should ever
wait
on
the worker. Normally, we probe the item, we set the flag and release
the
item. And move onto the next item, or exit.</code></pre>
</blockquote>
<pre><code> I am taking the safe route as this path is also invoked from users of
*libvlc*. We do not control who waits for what, and given that it is
not documented that a single waiter is max (by intention given the
implementaiton) the code is written as it is.</code></pre>
</blockquote>
<pre><code> You can never have more than one thread waiting in deletion path. Anything
else would lead to multiple frees.</code></pre>
</blockquote>
<pre><code> I have nver said that there should be two entities waiting for the
preparser deletion, I am talking about cancellations of preparser
requests.</code></pre>
</blockquote>
<pre><code> Which should never be waited for because it´s racy and pointless.</code></pre>
</blockquote>
<p>We have a very different set of opinion in terms of what is considered to be <em>“racy”</em> and <em>“pointless”</em>. If you feel like you have a better way of solving the describe set of problems together with the functionality now added (which I believe is a nice addition); please state so, or submit a patches.</p>
<p>If you are on the other hand stating that there is no problem, I fail to see what your opinion really is about the matter.</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> It also seems that I am forced to add, even though I thought
it was rather obvious from the implementation and comments, that there
is nothing stating that you cannot remove everything from the
preparser queue twice, or cancel a single request twice, or perhaps
cancel a group of requests by using the same id for all of them,
`background_worker_Destroy` implies `background_worker_Cancel` (with
the `id` argument being NULL to remove everything), but not the other
way around.</code></pre>
</blockquote>
</blockquote>
<p>/F</p>
</body>
</html>