[pypy-dev] FAQ entry

[Yuriy Taraday]

On Tue, Apr 7, 2015 at 8: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.
>

Sorry, I was under impression that GIL is being held by GC while finalizers
are being called. So this line from the blogpost must be wrong then:
> If any thread is holding either lock at this moment, the process
deadlocks.
I've checked it: https://gist.github.com/YorikSar/51b0b15fad41ef338e7f

So, deadlock is guaranteed only if we're trying to acquire it in the same
thread. We can handle at least this case. Although it seems pretty thin, as
#1 is just working around the problem.

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.
>

So it shouldn't matter if we run them in a separate thread.

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.
>

That's another reason for programmer to not rely on which thread __del__
runs in. So I think running them all in a separate thread would only make
things clearer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150407/37913808/attachment-0001.html>