[pypy-commit] extradoc extradoc: tweaks to the first section

antocuni noreply at buildbot.pypy.org
Fri Jan 13 15:10:21 CET 2012


Author: Antonio Cuni <anto.cuni at gmail.com>
Branch: extradoc
Changeset: r4023:12fcf122a300
Date: 2012-01-13 15:09 +0100
http://bitbucket.org/pypy/extradoc/changeset/12fcf122a300/

Log:	tweaks to the first section

diff --git a/blog/draft/tm.rst b/blog/draft/tm.rst
--- a/blog/draft/tm.rst
+++ b/blog/draft/tm.rst
@@ -14,9 +14,9 @@
 the point that in CPython even just manipulating the object's reference
 counter needs to be protected by the lock.
 
-Keeping your Python interpreter unchanged while managing to remove the
-infamous GIL: so far, this is regarded as the ultimate goal to enable
-true multi-CPU usage.  But we believe we have a plan to implement a
+So far, the ultimate goal to enable true multi-CPU usage has been to remove
+the infamous GIL from the interpreter, so that multiple threads could actually
+run in parallel.  But we think we have a plan to implement a
 different model for using multiple cores.  Believe it or not, this is
 *better* than just removing the GIL from PyPy.  You might get to use all
 your cores *without ever writing threads.*
@@ -24,7 +24,8 @@
 You would instead just use some event dispatcher, say from Twisted, from
 Stackless, or from your favorite GUI; or just write your own.  From
 there, you (or someone else) would add some minimal extra code to the
-event dispatcher's source code.  Then you would run your program on a
+event dispatcher's source code, to exploit the new transactional features
+offered by PyPy.  Then you would run your program on a
 special version of PyPy, and get some form of automatic parallelization.
 Sounds magic, but the basic idea is simple: start handling multiple
 events in parallel, giving each one its own *transaction.*  More about


More information about the pypy-commit mailing list