<p>Hi again,</p>
<p>On 16/08/25 16:19, 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> That´s what I don´t understand. How is deactivating the playlist,
 i.e. shutting down the playlist thread, making a difference here?</code></pre>
</blockquote>
<p>If the playlist is not deactivated prior to destroying the preparser, the playlist can indirectly cause the preparser to be invoked again at a time where the preparser is either about the be shut down, or has already been deleted.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> I don´t actually think that there is anything wrong with the
 preparser in the first place. The playlist fails to deregister its
 callbacks; the root cause of the bug lies in the playlist, not the
 preparser.</code></pre>
</blockquote>
<p>There are plenty of bugs in the current preparser implementation, among other things:</p>
<ul>
<li>the timeout mechanism is broken,</li>
<li>requests for preparsing is blocking at times where it should not,</li>
<li>there is really no reason for the preparser thread to be in <em>DETACH</em> state,</li>
<li>there are races due to weird locking mechanisms.</li>
</ul>
<p>I plan on creating tickets for my findings as soon as possible (prior to me submitting new implemenations in order to fix them).</p>
<hr style="height:1px;margin-bottom:20px;background-color:#ddd;color:#ddd" />
<h3 id="the-preparser-playlist">The Preparser + Playlist</h3>
<p>In terms of talking about the preparser and its relationship with the playlist it is broken because the playlist does not own the preparser, and the preparser does not own the playlist.</p>
<p>The above leads to a <em>chicken-and-egg</em> problem, and circumventing it is the purpose of the step we are discussing. Though as already stated I hope to solve it in a different manner all together (which includes a new preparsing implementation).</p>