RFC: Emscripten support for Python proposal

[hoodmane]

I am working on a proposal documenting the state of Python Emscripten support. The current text is here.

I would appreciate feedback from any Emscripten maintainers and community members who care to comment. Specifically, a significant portion of the text is spent describing the Emscripten target, runtime, and toolchain. I would like to make sure the Emscripten maintainers agree with the tone and substance of what I say here.

cc @sbc100 @kleisauke.

[sbc100]

Thanks @hoodmane!

Regarding the TTY/stdin/stdout issues, I think it would be great to get them fixed upstream (here).

Regarding "In the main browser thread, a dynamic library can only be loaded synchronously if it is at most 4 kilobytes", this no longer true. The limit was bumped some time last year I believe and its now 8mb. See https://groups.google.com/a/chromium.org/g/blink-dev/c/nJw2zwaiJ2s/m/EYPgC5D3LwAJ.

Regarding function pointers casts. Are you guys not using EMULATE_FUNCTION_POINTER_CASTS. IIRC that feature was specifically added to support python: https://emscripten.org/docs/tools_reference/settings_reference.html#emulate-function-pointer-casts.

[hoodmane]

Regarding the TTY/stdin/stdout issues, I think it would be great to get them fixed upstream (here).

I can work on that. I think the issue is that we need a more flexible API than Module.print and Module.printErr. I think we could add APIs similar to Pyodide's setStdin and setStdout:
https://pyodide.org/en/stable/usage/api/js-api.html#pyodide.setStdout

It is documented in Emscripten that the stream devices are all line buffering:
https://emscripten.org/docs/api_reference/Filesystem-API.html#setting-up-standard-i-o-devices
This makes sense because they were set up to use things like console.log() and prompt() which obviously have to be line buffered. But it would be good to allow non-line-buffered IO too.

The limit was bumped some time last year I believe and its now 8mb.

That's great news. Do you know what the status in Firefox and Safari is?

Regarding function pointers casts. Are you guys not using EMULATE_FUNCTION_POINTER_CASTS?

No, it took up dramatically too much stack space so we worked very hard to get rid of it. It turned out there are only ~12 specific call sites in the Python interpreter that were causing all of the problems, so it wasn't hard to add a JavaScript trampoline to fix them. Now that we want to be able to use stack switching, I replace them with a wasm-gc based solution if wasm-gc is available.

[sbc100]

I wonder if we can/should remove EMULATE_FUNCTION_POINTER_CASTS now? That would be great.