A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2011-August/113378.html below:

[Python-Dev] Software Transactional Memory for Python

[Python-Dev] Software Transactional Memory for Python [Python-Dev] Software Transactional Memory for PythonArmin Rigo arigo at tunes.org
Tue Aug 30 22:02:09 CEST 2011
Re-hi,

2011/8/29 Armin Rigo <arigo at 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.
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4