<div dir="ltr"><br><br><div class="gmail_quote">On Mon, Apr 6, 2015 at 4:44 PM Maciej Fijalkowski <<a href="mailto:fijall@gmail.com">fijall@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Apr 6, 2015 at 3:28 PM, Yuriy Taraday <<a href="mailto:yorik.sar@gmail.com" target="_blank">yorik.sar@gmail.com</a>> wrote:<br>
> On Mon, Apr 6, 2015 at 3:48 PM Maciej Fijalkowski <<a href="mailto:fijall@gmail.com" target="_blank">fijall@gmail.com</a>> wrote:<br>
>><br>
>> maybe we should add something along those lines to FAQ<br>
>><br>
>> <a href="http://emptysqua.re/blog/pypy-garbage-collection-and-a-deadlock/" target="_blank">http://emptysqua.re/blog/pypy-<u></u>garbage-collection-and-a-<u></u>deadlock/</a><br>
><br>
><br>
> Can't it be fixed? I see 2 possible solutions here:<br>
> 1. We can detect deadlock (any lock contention during GC round will become<br>
> deadlock) and bail out of GC round early to try again later or skip freeing<br>
> this object (and mark all objects referenced by it).<br>
> 2. We can defer all calls to __del__ until after GC round and run them in a<br>
> separate Python thread which would allow them to yield processing to let<br>
> other threads free some lock.<br>
><br>
> I know that either of these solutions would change semantics a bit, but it<br>
> shouldn't affect user's code.<br>
<br>
as you can see from the blog post *any* change does affect user code.</blockquote><div><br></div><div>Well, I mean if we let user use locks as expected, it won't affect it in any bad way.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Note that finalizers are not called during GC, but at some later</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
"safer" stage, where all the internals are in a sane state.</blockquote><div><br></div><div>It's still a part of GC pause (or how you call it) when GIL is taken and won't ever be released back.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Not sure how you would do 1, really (a global flag on locks?),</blockquote><div><br></div><div>Yes, smth like a global flag that would be set during that stage and Lock.acquire would check it to see if there's a deadlock. We can at least throw some exception or warning to make it clearer to user what happened.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2 is something Java does.<br></blockquote><div><br></div><div>It seems to be the most sane way to do it. It avoids this special state in which __del__ code is run.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">General FAQ entry should say "avoid __del__ doing any substantial job<br>
at any cost" I would think, whacking at locks is like lipstick on a<br>
pig.<br></blockquote><div><br></div><div>Yes, #1 would just cover one possible problem with them. </div></div></div>