[Python-ideas] [Python-Dev] [ANN]: "newthreading" - an approach to simplified thread usage, and a path to getting rid of the GIL
fuzzyman at gmail.com
Tue Jun 29 01:54:11 CEST 2010
On 29 Jun 2010, at 00:40, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 28 Jun 2010 16:09:55 -0700
> Guido van Rossum <guido at 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).
> Python-ideas mailing list
> Python-ideas at python.org
More information about the Python-ideas