[pypy-commit] pypy default: Mention what pypy-stm is *not* good for

arigo noreply at buildbot.pypy.org
Tue Mar 24 20:53:26 CET 2015


Author: Armin Rigo <arigo at tunes.org>
Branch: 
Changeset: r76545:68f15684fb4d
Date: 2015-03-24 20:53 +0100
http://bitbucket.org/pypy/pypy/changeset/68f15684fb4d/

Log:	Mention what pypy-stm is *not* good for

diff --git a/pypy/doc/stm.rst b/pypy/doc/stm.rst
--- a/pypy/doc/stm.rst
+++ b/pypy/doc/stm.rst
@@ -25,8 +25,8 @@
 .. _`2nd call for donation`: http://pypy.org/tmdonate2.html
 
 
-Introduction
-============
+What pypy-stm is for
+====================
 
 ``pypy-stm`` is a variant of the regular PyPy interpreter.  (This
 version supports Python 2.7; see below for `Python 3`_.)  With caveats_
@@ -55,6 +55,27 @@
   and `transaction.TransactionQueue`_.
 
 
+...and what pypy-stm is not for
+-------------------------------
+
+``pypy-stm`` gives a Python without the GIL.  This means that it is
+useful in situations where the GIL is the problem in the first place.
+(This includes cases where the program can easily be modified to run
+in multiple threads; often, we don't consider doing that precisely
+because of the GIL.)
+
+However, there are plenty of cases where the GIL is not the problem.
+Do not hope ``pypy-stm`` to be helpful in these cases!  This includes
+all programs that use multiple threads but don't actually spend a lot
+of time running Python code.  For example, it may be spending all its
+time waiting for I/O to occur, or performing some long computation on
+a huge matrix.  These are cases where the CPU is either idle, or in
+some C/Fortran library anyway; in both cases, the interpreter (either
+CPython or the regular PyPy) should release the GIL around the
+external calls.  The threads will thus not end up fighting for the
+GIL.
+
+
 
 Getting Started
 ===============


More information about the pypy-commit mailing list