[pypy-dev] FAQ entry

[Armin Rigo]

Hi Yuriy,

On 7 April 2015 at 16:00, Yuriy Taraday <yorik.sar at 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.