Repository navigation
Allow Subinterpreters on WASI/Emscripten Builds #135190
Description
Activity
Do the tests require processes for any reason? Otherwise I don't remember explicitly turning them off.
@hoodmane can confirm, but IIRC, on Emscripten, the restriction is the lack of threads (or, at least, the decision to disable the limited thread support that is available on Emscripten because of security and compatibility concerns).
Reacted by Hood ChathamYeah, threads don't work very well with dynamic linking on Emscripten. I think as long as you first load dynamic libraries, then start threads it's probably okay. But it's complex to support and I don't personally care enough. Subinterpreters don't seem like they can be all that useful without threading.
There are definitely some use cases for subinterpreters outside concurrency. There's some discussion surrounding this on the PEP 734 acceptance yesterday. I think the clearest one is that you can change
sys.pathto allow conflicting versions of dependencies to be loaded in the same process.@ericsnowcurrently are you planning to try and turn on support or waiting on someone else to do it?
I haven't had time to think about it much. 😄
Reacted by Brett Cannon
Currently using multiple interpreters on WASI and Emscripten builds is disallowed. This is reflected in various places, including
configure, the test suite, and the docs. I don't recall why the feature was disallowed (maybe confusion about a relationship with threads?), but there shouldn't be any need to disallow them.CC @brettcannon