On 29 Jun 2010, at 00: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.
Full agreement. Ironclad, a project to enable the use of Python C extensions with IronPython - which has a generational moving GC, uses a hybrid approach. It allows C extensions to use reference counting but manipulates the reference count so that it can only drop to zero once there are no references left on the IronPython side. There are complications with this approach, which Ironclad handles, but that would be much easier when we have control over the implementation (Ironclad doesn't change the IronPython implementation). No link I'm afraid, sending from a mobile device. Incidentally, Ironclad also 'fakes' the GIL as IronPython has no GIL. In theory this could cause problems for C extensions that aren't thread safe but that hasn't yet been a problem in production (Ironclad is mainly used with numpy). Michael Foord
Regards
Antoine.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas