Maybe it'd be better to put 'atomic' in the threading module? On 2011-08-30, at 4:02 PM, Armin Rigo wrote:
> Re-hi, > > 2011/8/29 Armin Rigo <ar...@tunes.org>: >>> The problem is that many locks are actually acquired implicitely. >>> For example, `print` to a buffered stream will acquire the fileobject's >>> mutex. >> >> Indeed. >> (...) >> I suspect that I need to do a more thorough review of the stdlib (...) > > I found a solution not involving any change in CPython, and updated > the patch. The solution is to say that a "with atomic" block doesn't > completely prevent other threads from re-acquiring the GIL, but only > prevents them from proceeding to the following bytecode. So if > another thread is currently suspended in a place that releases the GIL > for other reasons, then this other thread can still be switched to as > normal, and continue running until the end of the current bytecode. I > think it's sane enough for the original purpose, and avoids most > deadlock cases. > > > 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/yselivanov.ml%40gmail.com _______________________________________________ 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
