> We should probably document where all of these globals lists are > instead of relying on looking for all file level static declarations > or something. I'm not sure what would be gained here, except for people occasionally (i.e. every three years) asking how they can best get rid of the GIL. > Or would there be benefit to moving things like this to > the interpreter struct so that threads within a single interpreter > call are locked but interpreters can act much more independently? The "multiple interpreter" feature doesn't quite work, and likely won't for a foreseeable future; specifically, objects can easily leak across interpreters. That's actually not a problem for immutable objects, like the strings, but here come the global objects into play which PJE mentions: types, including exceptions. Making them per-interpreter would probably break quite some code. As for the cached strings - it would be easy to make a global table of these, e.g. calling them _PyS__init__, _PyS__add__, and so on. These could be initialized at startup, simplifying the code that uses them because they don't have to worry about failures. Regards, Martin
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