On Tue, Apr 7, 2015 at 7: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. > > 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) _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
