[pypy-dev] FAQ entry

[Maciej Fijalkowski]

On Tue, Apr 7, 2015 at 7:18 PM, Armin Rigo <arigo at tunes.org> wrote:
> 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.
>

Are you sure this is true for the case where object is found inside a
cycle? (these days, they're run, not sure if in 2.7 or 3.x)