<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 25 May 2017 at 08:06 Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 25 May 2017 at 13:30, Guido van Rossum <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>> wrote:<br>
> Hm... Curiously, I've heard a few people at PyCon mention they thought<br>
> subinterpreters were broken and not useful (and they share the GIL anyways)<br>
> and should be taken out.<br>
<br>
Taking them out entirely would break mod_wsgi (and hence the use of<br>
Apache httpd as a Python application server), so I hope we don't<br>
consider going down that path :)<br>
<br>
As far as the GIL goes, Eric has a few ideas around potentially<br>
getting to a tiered locking approach, where the GIL becomes a<br>
Read/Write lock shared across the interpreters, and there are separate<br>
subinterpreter locks to guard actual code execution. That becomes a<br>
lot more feasible in a subinterpreter model, since the eval loop and<br>
various other structures are already separate - the tiered locking<br>
would mainly need to account for management of "object ownership" that<br>
prevented multiple interpreters from accessing the same object at the<br>
same time.<br>
<br>
However, I do think subinterpreters can be accurately characterised as<br>
fragile, especially in the presence of extension modules. I also think<br>
a large part of that fragility can be laid at the feet of them<br>
currently being incredibly difficult to test - while _testembed<br>
includes a rudimentary check [1] to make sure the subinterpreter<br>
machinery itself basically works, it doesn't do anything in the way of<br>
checking that the rest of the standard library actually does the right<br>
thing when run in a subinterpreter.<br>
<br>
So I'm +1 for the idea of exposing a low-level CPython-specific<br>
_interpreters API in order to start building out a proper test suite<br>
for the capability, and to let folks interested in working with them<br>
do so without having to write a custom embedding application ala<br>
mod_wsgi.<br>
<br>
However, I think it's still far too soon to be talking about defining<br>
a public supported API for them - while their use in mod_wsgi gives us<br>
assurance that they do mostly work in CPython, other implementations<br>
don't necessarily have anything comparable (even as a private<br>
implementation detail), and the kinds of software that folks run<br>
directly under mod_wsgi isn't necessarily reflective of the full<br>
extent of variation in the kinds of code that Python developers write<br>
in general.<br></blockquote><div><br></div><div>I'm +1 on Nick's idea of the low-level, private API existing first to facilitate testing, but putting off any public API until we're sure we can make it function in a way we're happy with to more generally expose. </div></div></div>