I have a C++ server that loads user-created DLLs, wakes them up via upcalls, and then hosts them in a shared address space. I would like to support Python. Unfortunately, Python is single threaded, hence simply loading two Python DLLs in my server without any kind of wrapper (to hide them from one-another) violates the Python runtime system constraints.
It seems to me that I could just statically link the user’s DLL to the Python libraries, edit the symbol table in the .so file and change all globals other than my upcall entry point into locals, and by doing so could containerize Python: it wouldn’t know that I’m running multiple instances of the runtime, the instances wouldn’t share variables, and in principle, should coexist without any kind of interference.
I would definitely be doing concurrent upcalls on multiple threads from my server, but never twice to the same DLL, so the worry centers on concurrency: conflicts that zapping the symbol table can’t resolve. For example: there are a few Linux system calls that are address-space wide, such as sbrk(), and signal interception. Does anyone know if Python’s runtime system uses those features?
More broadly, has this been tried? Does anyone know, from prior experience, whether my idea would work? Or does the Python runtime have some sort of weird dependency that genuinely makes it impossible to run two non-conflicting DLLs in this manner?