-> > Are you using separate interpreters or one interpreter with multiple -> > threads? It sounds like the latter. If you use the latter than -> > definately things like the process address space and the -> > current working directory are shared across the threads. I don't -> > think I understand your design. Can you explain the architecture -> > of PyWX? -> > -> -> """Because sub-interpreters (and the main interpreter) are part of -> the same process, the insulation between them isn't perfect -- for -> example, using low-level file operations like os.close() they can -> (accidentally or maliciously) affect each other's open files. -> Because of the way extensions are shared between (sub-)interpreters, -> some extensions may not work properly; this is especially likely -> when the extension makes use of (static) global variables, or when -> the extension manipulates its module's dictionary after its -> initialization""" -> -> So we are basically stuck. We can't link against Python multiple -> times, so our only avenue to provide multiple interpreter instances -> is to use the "Py_InterpreterNew" call and hope for the best. -> -> Any hope for better interpreter isolation in 2.0? (2.1?) Perhaps a better question is: is there any way to get around these problems without moving from a threaded model (which we like) to a process model? Many of the problems we're running into because of this lack of interpreter isolation are due to the UNIX threading model, as I see it. For example, the low-level file operation interference, cwd problems, and environment variable problems are all caused by UNIX's determination to share this stuff across threads. I don't see any way of changing this without causing far more problems than we fix. cheers, --titus
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