Antoine Pitrou added the comment: 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) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14976> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
