Author: Armin Rigo <[email protected]> Branch: extradoc Changeset: r4022:397ef6a17af3 Date: 2012-01-13 14:59 +0100 http://bitbucket.org/pypy/extradoc/changeset/397ef6a17af3/
Log: Tweaks diff --git a/blog/draft/tm.rst b/blog/draft/tm.rst --- a/blog/draft/tm.rst +++ b/blog/draft/tm.rst @@ -1,8 +1,8 @@ Transactional Memory ==================== -Here is an update about the previous blog post about the -`Global Interpreter Lock`__ (GIL). +Here is an update about the `previous blog post`__ about the +Global Interpreter Lock (GIL). .. __: http://morepypy.blogspot.com/p/global-interpreter-lock-or-how-to-kill.html @@ -11,8 +11,8 @@ prevents multiple threads from actually running at the same time. The reason to do that is that it would have desastrous effects in the interpreter if both threads access the same object concurrently --- to -the point that in CPython even just manipulating the reference counter -needs to be protected by the lock. +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 @@ -82,11 +82,12 @@ might be simpler, but you still have to learn and use subtle locking patterns or a complex inter-process library, which is overkill for the purpose. I would even argue that this is similar to how we might feel a -priori that automatic memory management is overkill in small programs ---- of course anyone who wrote a number of 15-line Python scripts knows -this to be wrong. This is even *so* wrong that the opposite is obvious -nowadays: it makes no sense whatsoever to manage object lifetimes -explicitly in most small scripts. +priori that automatic memory management is unnecessary in small programs +--- but of course anyone who wrote a number of 15-line Python scripts +knows this to be wrong. This is even *so* wrong that the opposite is +obvious nowadays: it makes no sense whatsoever to manage object +lifetimes explicitly in most small scripts. A garbage collector is not +overkill; it is part of the basics that you expect. (I think the same will eventually be true for using multiple CPUs, but the correct solution will take time to mature, like garbage collectors _______________________________________________ pypy-commit mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-commit
