<div dir="auto"><div>Cool. Thanks, Nick!<div dir="auto"><br></div><div dir="auto">I did experiments based on this idea (<a href="https://github.com/stephanreiter/cpython/commit/3bca91c26ac81e517b4aa22302be1741b3315622" target="_blank" rel="noreferrer">https://github.com/stephanreiter/cpython/commit/3bca91c26ac81e517b4aa22302be1741b3315622</a>) and haven't rejected it yet. :-)</div><div dir="auto"><br></div><div dir="auto">Together with the other fix (<a href="https://github.com/stephanreiter/cpython/commit/c1afa0c8cdfab862f409f1c7ff02b189f5191cbe">https://github.com/stephanreiter/cpython/commit/c1afa0c8cdfab862f409f1c7ff02b189f5191cbe</a>), numpy at least is happy in my Python-hosting app.</div><div dir="auto"><br></div><div dir="auto">I will pursue the idea of swapping sys.modules in a single Interpreter now because that wouldn't require patching Python and I might get the mileage out of this approach I need.</div><div dir="auto"><br></div><div dir="auto">Still interested in improving sub-interpreters, though. I just need to balance short and long term solution. :-)</div><div dir="auto"><br></div><div dir="auto">Stephan</div><br><br><div class="gmail_quote"><div dir="ltr">Den søn. 27. jan. 2019, 15.17 skrev Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank" rel="noreferrer">ncoghlan@gmail.com</a>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 24 Jan 2019 at 05:45, Stephan Reiter <<a href="mailto:stephan.reiter@gmail.com" rel="noreferrer noreferrer" target="_blank">stephan.reiter@gmail.com</a>> wrote:<br>
> If we create a fresh OS thread and make it call PyGILState_Ensure, it<br>
> won't have a PyThreadState saved under autoTLSkey. That means it will<br>
> create one using the main interpreter. I, as the developer embedding<br>
> Python into my application and using multiple interpreters, have no<br>
> control here. Maybe I know that under current conditions a certain<br>
> other interpreter should be used.<br>
><br>
> I'll try to provoke this situation and then introduce a callback from<br>
> Python into my application that will allow me to specify which<br>
> interpreter should be used, e.g. code as follows:<br>
><br>
> PyInterpreter *pickAnInterpreter() {<br>
>   return activePlugin ? activePlugin->interpreter : nullptr; //<br>
> nullptr maps to main interpreter<br>
> }<br>
><br>
> PyGILState_SetNewThreadInterpreterSelectionCallback(&pickAnInterpreter);<br>
><br>
> Maybe rubbish. But I think a valuable experiment that will give me a<br>
> better understanding.<br>
<br>
That actually sounds like a pretty plausible approach to me, at least<br>
for cases where the embedding application maintains some other state<br>
that lets it know which interpreter a new thread should be associated<br>
with. The best aspect of it is that it would let the embedding<br>
application decide how to handle registration of previously unknown<br>
threads with the Python runtime *without* requiring that all existing<br>
extension modules switch to a new thread registration API first.<br>
<br>
I'll pass the concept along to Graham Dumpleton (author of the<br>
mod_wsgi module for Apache httpd) to see if an interface like this<br>
might be enough to resolve some of the major compatibility issues<br>
mod_wsgi currently encounters with subinterpreters.<br>
<br>
Cheers,<br>
Nick.<br>
<br>
-- <br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" rel="noreferrer noreferrer" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</blockquote></div>
</div></div>