On Mon, Jun 28, 2010 at 17:40, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Mon, 28 Jun 2010 16:09:55 -0700 Guido van Rossum <guido@python.org> wrote:
I'm moving this thread to python-ideas, where it belongs. [...]
For the record, I really think the solution to the "try to remove the GIL" problem is to... try to remove it. I believe it implies several preparatory steps: - take full control of memory allocation - on top of that, devise a full garbage collector (probably including a notion of external references such that existing ways of writing C extensions are still correct) - then, do the the tedious, delicate grunt work of adding locking to critical structures without slowing them down (too much)
Trying to invent schemes to make multithreading easier to program with is a nice endeavour in itself, but quite orthogonal IMO.
+1. Designing an API in C for a precise GC is tedious, and would probably be very ugly, but it's entirely doable. We simply need the will to go through with it. I can't say what the overhead would look like, but so long as it scales well and it's a compile-time option it should find plenty of users.