Home Original page

[Python-ideas] solving multi-core Python

Antoine Pitrou solipsis at pitrou.net
Sun Jun 21 13:52:36 CEST 2015 
On Sun, 21 Jun 2015 13:41:30 +0200
Sturla Molden <sturla.molden at gmail.com>
wrote:
>  From the perspective of software design, it would be good it the 
> CPython interpreter provided an environment instead of using global 
> objects. It would mean that all functions in the C API would need to 
> take the environment pointer as their first variable, which will be a 
> major rewrite. It would also allow the "one interpreter per thread" 
> design similar to tcl and .NET application domains.

From the point of view of API compatibility, it's unfortunately a no-no.

> The reason IPC in multiprocessing is slow is due to calling pickle, it 
> is not the IPC in itself.

No need to be pedantic :-) The "C" means communication, and pickling
objects is part of the communication between Python processes.

> All in all, I think we are better off finding a better way to share 
> Python objects between processes.

Sure. This is however a complex and experimental topic (how to share a
graph of garbage-collected objects between independant processes), with
no guarantees of showing any results at the end.

> P.S. Another thing to note is that with sub-interpreters, you can forget 
> about using ctypes or anything else that uses the simplified GIL API 
> (e.g. certain Cython generated extensions).

Indeed, the PyGILState API is still not subinterpreter-compatible.
There's a proposal on the tracker, IIRC, but the interested parties
never made any progress on it.

Regards

Antoine.
More information about the Python-ideas mailing list