[Python-ideas] Exposing CPython's subinterpreter C-API in the stdlib.

Guido van Rossum guido at python.org
Fri May 26 13:30:00 EDT 2017

On Fri, May 26, 2017 at 8:28 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> [...] assuming the rest of idea works out
> well, we'd eventually like to move to a tiered model where the GIL
> becomes a read/write lock. Most code execution in subinterpreters
> would then only need a read lock on the GIL, and hence could happily
> execute code in parallel with other subinterpreters running on other
> cores.

Since the GIL protects refcounts and refcounts are probably the most
frequently written item, I'm skeptical of this.

> However, that aspect of the idea is currently just hypothetical
> handwaving that would need to deal with (and would be informed by) the
> current work happening with respect to the GILectomy, as it's not
> particularly interesting as far as concurrency modeling is concerned.
> By contrast, being able to reliably model Communicating Sequential
> Processes in Python without incurring any communications overhead
> though (ala goroutines)? Or doing the same with the Actor model (ala
> Erlang/BEAM processes)?
> Those are *very* interesting language design concepts, and something
> where offering a compelling alternative to the current practices of
> emulating them with threads or coroutines pretty much requires the
> property of zero-copy ownership transfer.

But subinterpreters (which have independent sys.modules dicts) seem a poor
match for that. It feels as if you're speculating about an entirely
different language here, not named Python.

--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170526/c4731ead/attachment.html>

More information about the Python-ideas mailing list