Do not release the GIL during object destruction

[matthewyu0311 (Matthew)]

@Liz

documenting implementation details related to the GIL for people to rely upon

The point is documenting them for people to rely upon, it’s the opposite: documenting them so that people don’t inadvertently rely upon them.

[da-woods]

Going back to the finalizers using locks, I think even something like this becomes dodgy:

from threading import Lock

logging_lock = Lock()

def log(msg)
    with logging_lock:
        ... # log to file or database or somewhere...

class C:
    def __del__(self):
        log("C instance was finalized")

because if another Python thread holds the lock, then that thread can never acquire the GIL and run far enough to release the lock.

That doesn’t involve any (obvious) C code (although I know threading will be implented in C) and nothing about it seems hugely controversial to me.

[pitrou (Antoine Pitrou)]

@pf_moore

I don’t understand how the GIL guarantees that the += operation on integers is atomic. Isn’t it the code for the += operation that determines that?

More precisely, for integers, it’s the fact that integers are immutable, so a += b cannot mess with the object currently referred by a – it has to create a new object that a will then rebind to.