Hi Armin, > This is basically dangerous, because it corresponds to taking lock > "GIL" and lock L, in that order, whereas the thread B takes lock L and > plays around with lock "GIL" in the opposite order. I think a > reasonable solution to avoid deadlocks is simply not to use explicit > locks inside "with atomic" blocks.
The problem is that many locks are actually acquired implicitely. For example, `print` to a buffered stream will acquire the fileobject's mutex. Also, even if the code inside the "with atomic" block doesn't directly or indirectely acquire a lock, there's still the possibility of asynchronous code that acquire locks being executed in the middle of this block: for example, signal handlers are run on behalf of the main thread from the main eval loop and in certain other places, and the GC might kick in at any time. > Generally speaking it can be regarded as wrong to do any action that > causes an unbounded wait in a "with atomic" block, Indeed. cf _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
