News for hackers. Stuff that matters.
Re:Solving multi-core Python by smegel on Thursday July 09, 2015 @11:47PM (#9862196)
> All Python has to do is put all interpreter state into a single struct to allow for completely independent interpreter instances.

But that is not what threading means. If you want "completely independent interpreters" just fork. Threading means you share everything.

> Then the GIL can be discarded altogether

And then you start sharing variables between interpreters, and you gets lots of little baby GILs to contend with! How fun will that be? Not very.

Re:Solving multi-core Python by Frondo on Thursday July 09, 2015 @11:55PM (#9862230)
That's how Tcl does it. Each thread gets its own Tcl interpreter, and you communicate among them via message passing. It lets you avoid the context switch that way.
Re:Solving multi-core Python by frozenport on Friday July 10, 2015 @12:02AM (#9862245)
There is a difference between threads and processes. What you outline is how the python multiprocessing library works.
Re:Solving multi-core Python by sitkack on Friday July 10, 2015 @02:39AM (#9862589)
Think of it like running multiple python processes inside the same memory space so that copying between interpreters is by reference, not value. Nothing has to be serialized.
Re:Solving multi-core Python by onnoonno on Friday July 10, 2015 @08:29AM (#9863511)
How do you avoid damaging the consistency of Python objects then?

I think the only way to do that would be to have a reentrant lock for each object individually. Isn't that potentially a big performance issue?

I think that is the main reason behind this quote from the article:

> Several attempts have been made over the years and failed to do it without sacrificing single-threaded performance.