<div dir="ltr"><div class="gmail_quote">On Wed, Apr 8, 2015 at 1:57 PM 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">On 8 April 2015 at 11:43, Yuriy Taraday <<a href="mailto:yorik.sar@gmail.com" target="_blank">yorik.sar@gmail.com</a>> wrote:<br>
> It's already broken if it's used in multithreaded app. For single-threaded<br>
> apps we can make an exception and keep things running as they are now, i.e.<br>
> keep it single-threaded. This will also prevent unnecessary multithreading<br>
> initialization.<br>
<br>
You'd end up with cases where you can have a deadlock in<br>
single-threaded programs that magically goes away if you just add<br>
anywhere the line "thread.start_new_thread(<u></u>lambda:None, ())"...  But<br>
maybe creating lock objects should be enough to change where<br>
destructors run?  You can't easily have deadlocks without user lock<br>
objects.<br></blockquote><div><br></div><div>Having locks in single-threaded app is rather strange, but it can be some library code, so programmer can be not aware of them and rely on that "serialized __del__".</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Or, if you care about deadlocks, maybe your Python program should<br>
explicitly start it own finalizer thread.  Your<br>
potentially-deadlocking __del__ methods should use a decorator that,<br>
when called, simply puts the actual method into a Queue.Queue which is<br>
consumed by this finalizer thread.  It would be the same, but not<br>
transparent.<br></blockquote><div><br></div><div>That would be creating new references to self in __del__ which is bad (at least docs say so). And after that these references will be gone once again and __del__ will be called again.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think that the idea of doing it transparently may be interesting,<br>
but it needs some more careful design before we can think about<br>
changing PyPy like that.  (Not that there is *any* idea about the GC<br>
that doesn't require careful design :-)<br></blockquote><div><br></div><div>Oh, sure. I just think that we should at least consider this approach.</div></div></div>