[pypy-dev] FAQ entry

[Yuriy Taraday]

Sorry for hijacking thread. I hope I won't hider it too much.

On Mon, Apr 6, 2015 at 10:05 PM Armin Rigo <arigo at tunes.org> wrote:

> (2) cannot be done in Python without major changes in semantics.  User
> code that makes no use of threads, for example, certainly doesn't
> expect to be careful about multithreading in the __del__ methods.
>

GC introduces concurrency to user code anyway: call to some __del__ method
can happen in any time in user code, so it might be called in a separate
thread just as well (it'll be serialized by GIL anyway). On the other hand
single-threaded program should not suffer any deadlocks since there's no
locks in it, so we can use this approach only in multithreaded programs.

__del__ methods themselves should already be pretty isolated in the sense
that they can't assume anything about state of objects (except self which
belongs only to them when they are executed).

(1) is hard too.  What is hard is to decide when acquiring a lock in a
> __del__ is safe or not.  For example, it would not be safe if the lock
> is some global lock.  But it would be safe if the lock belongs to the
> object being finalized, in which case (we can hope that) nobody else
> can see it any more.


> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150407/1c47b650/attachment.html>