Author: fijal
Branch: extradoc
Changeset: r5824:155c9cbc30c7
Date: 2017-08-04 11:26 +0200
http://bitbucket.org/pypy/extradoc/changeset/155c9cbc30c7/

Log:    work on the blog post

diff --git a/blog/draft/remove-gil.rst b/blog/draft/remove-gil.rst
--- a/blog/draft/remove-gil.rst
+++ b/blog/draft/remove-gil.rst
@@ -24,5 +24,35 @@
 already have backing for about 1/3. If we can get a $100k contract, we would
 make it our priority to deliver before the end of the year.
 
+People asked several questions, so I'll try to answer the technical parts
+here.
+
+* What would the plan entail?
+
+We've already done the work on Garbage Collector to allow doing multi
+threaded programs in RPython. "all" that's left is adding locks on mutable
+data structures everywhere in PyPy codebase. Since it'll significantly 
complicated
+our workflow, we need to see real interest in that topic, backed up by
+commercial contracts, otherwise we're not going to do it.
+
+* Why the STM effort did not work out?
+
+STM was a research project that proved that the idea is possible. However,
+the amount of user effort that's required to make programs run nicely
+parallelizable is both significant and we never managed to develop tools
+that would help nicely. At the present time we're not sure if more manpower
+spent on tooling would improve the situation or idea is doomed. The whole
+approach also ended up being a significant overhead on single threaded 
programs,
+which means that it's very easy to make your programs slower.
+
+* Would subinterpreters not be a better idea?
+
+Python is a very mutable language - there is tons of mutable state and
+basic objects that are compile time in other languages, like classes and 
functions
+are mutable at runtime. That means that sharing things between subinterpreters 
would
+be restricted to basic immutable data structures, which defeats the point 
compared
+to multi-processing approach. We don't believe it's a viable approach without
+seriously impacting the semantics of the language.
+
 Best regards,
 Maciej Fijalkowski
_______________________________________________
pypy-commit mailing list
[email protected]
https://mail.python.org/mailman/listinfo/pypy-commit

Reply via email to