Hi Yuriy, On 7 April 2015 at 16:00, Yuriy Taraday <yorik....@gmail.com> wrote: >> We can't even be sure that an actual deadlock situation encountered in >> a __del__ is really a deadlock; maybe a different thread will come >> along and release that lock soon... I think this is a problem that is >> just as hard as the general deadlock problem (i.e. unsolvable, but the >> user can use some tools to help him figure out deadlocks when they >> really happen). > > It will 100% deadlock if the lock in question is held by another thread > since we hold GIL that's needed to release it.
No, that's wrong. You can't use the GIL as argument for the behavior of a long-running piece of Python code. The GIL is released periodically, also inside the __del__ method. If that __del__ method tries to acquire a lock that is already acquired, it suspends the thread, but as usual it does so by first releasing the GIL and letting other threads run. You're correct in that we don't know which thread the __del__ method runs in, and so we don't know exactly which thread's execution is suspended until the end of the __del__ method. This is in contrast with *some* cases in CPython, notably cases where we know an object 'x' is only ever created, manipulated, and freed in some thread; then (and only in this case) on CPython we know that the __del__ method will also be run in that same thread. That's not the case on PyPy (as long as you have more than one active thread, at least). Still, it's unclear what we can change about it. A bientôt, Armin. _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
