On Tue, Apr 7, 2015 at 8:18 PM Armin Rigo <ar...@tunes.org> wrote: > 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. >
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.
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
