Le 18/08/2017 à 17:37, Yury Selivanov a écrit :
> 
> Is it guaranteed that the GC will happen in the same thread that is holding the lock?

By design, if it's called from a different thread, Queue will cope fine:
__del__ implicitly calls RLock.acquire which, if the RLock is already
taken, releases the GIL and waits until the RLock is released by the
other thread.

The contentious case is when a Queue method call is interrupted by some
asychronous event (signal handler, GC callback) that calls another Queue
method in the same thread.

Note, in my patch, the RLock isn't even used for its recursive
properties, but only because it allows to query if it's already taken by
the current thread (using a private method that's already used by
threading.Condition, and which could reasonably be made public IMHO).

(on that topic, the pure Python implementation of RLock doesn't
guarantee proper reentrancy against asynchronous events itself -- see
https://bugs.python.org/issue13697 --, but fortunately we use a C
implementation by default which is pretty much ok)