<div dir="ltr"><div class="gmail_quote">On Wed, Apr 8, 2015 at 10:16 AM Armin Rigo <<a href="mailto:arigo@tunes.org">arigo@tunes.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Yuriy,<br>
<br>
It seems that now you've understood the problems, so please re-read my<br>
previous answers :-)<br>
<br>
In particular, I try to give a situation where even what looks like a<br>
deadlock might not be one (because any thread can release any lock),<br>
and why we can't always run finalizers in a separate thread (because<br>
simple non-multithreaded programs don't expect concurrency when<br>
running dels).<br></blockquote><div><br></div><div>I see problem with solution #1 since deadlock is hard to detect. It actually is a workaround, so it won't work all the time and it's not a prefered solution.</div><div>I still don't see problem with solution #2. I've been sent a link [0] to a post that shows that signals and finalizers are "unexpected concurrency" anyway. Furthermore even in multithreaded app we can't predict which thread will end up executing them. So my argument is: why not make it clear that __del__ will run in a separate thread instead of trying to pretend that it's something more predictable than that?</div><div><br></div><div>[0] <a href="https://wingolog.org/archives/2012/02/16/unexpected-concurrency">https://wingolog.org/archives/2012/02/16/unexpected-concurrency</a></div></div></div>