Repository navigation
Allow Subinterpreters on WASI/Emscripten Builds #135190
Description
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
Activity
brettcannon commentedon Jun 5, 2025
Do the tests require processes for any reason? Otherwise I don't remember explicitly turning them off.
freakboy3742 commentedon Jun 5, 2025
@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).
hoodmane commentedon Jun 5, 2025
Yeah, 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.
ZeroIntensity commentedon Jun 6, 2025
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.brettcannon commentedon Jun 26, 2025
@ericsnowcurrently are you planning to try and turn on support or waiting on someone else to do it?
ericsnowcurrently commentedon Jun 26, 2025
I haven't had time to think about it much. 😄