Hi Antoine, > You then risk deadlocks. Say: > (...)
Yes, it is indeed not a solution that co-operates transparently and deadlock-freely with regular locks. You risk the same kind of deadlocks as you would when using only locks. The reason is similar to threads that try to acquire two locks in succession. In your example: > - thread A is inside a "with atomic" and calls a library function which > tries to take lock L 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. Generally speaking it can be regarded as wrong to do any action that causes an unbounded wait in a "with atomic" block, but the solution I chose to implement in my patch is to still allow them, because it doesn't make much sense to say that "print" or "pdb.set_trace()" are forbidden. A bientôt, Armin. _______________________________________________ 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
