Greg Ewing wrote: > Paul Moore wrote: >> Do you know if these remaining problems are listed anywhere? > > There was a big discussion about this in comp.lang.python > not long ago. Basically all the built-in types and constants > are shared between interpreters, which means you still need > a GIL to stop different interpreters stepping on each other's > toes. That kind of thing is under the core's control though - the 2.x module initialisation problem means that you can't write a multiple interpreter friendly extension module even if you want to. The new per-interpreter state mechanism could also be used internally by the core to duplicate some of that global state for each new interpreter. I see the introduction of the interpreter specific state mechanism as a big step because it provides an underlying mechanism that makes the problem solvable *in principle* through a combination of per-interpreter state and finer grained shared locking, making it just a practical implementation problem to see if that can be done without adversely impacting single interpreter performance. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia ---------------------------------------------------------------
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4