This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ethan smith
Recipients Beuc, Simon Biggs, ethan smith, pmpp, serhiy.storchaka, xtreak
Date 2021-05-20.23:49:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1621554568.4.0.0985089234451.issue40280@roundup.psfhosted.org>
In-reply-to
Content
I think the first thing we should do is figure out whether we want to support Emscripten or WASI (or both).

Emscripten uses Javascript polyfills for some syscalls, while WASI makes direct calls the VM it is running in. They both can use WebAssembly for executing the code. This means Emscripten has wider API support, but WASI is lighter weight in many ways.

I think starting with patches to support Emscripten would be best, as it is easier to target, then add support for WASI later.

I think supporting WASI has a lot of value, because it can be run deterministically, which would be great for data science (Imagine a jupyter notebook that runs the same everywhere!)

One issue with WASI, and may be an issue with Emscripten, is threads. In 3.8 (or 3.9?) threadless builds were removed. However, WebAssembly's threading API is not really meant to emulate pthread, and SharedArrayBuffer, the primitive it is built on, is disabled in several browsers due to Spectre concerns.

Would patches to re-add a threadless build mode be accepted?
History
Date User Action Args
2021-05-20 23:49:28ethan smithsetrecipients: + ethan smith, pmpp, serhiy.storchaka, xtreak, Simon Biggs, Beuc
2021-05-20 23:49:28ethan smithsetmessageid: <1621554568.4.0.0985089234451.issue40280@roundup.psfhosted.org>
2021-05-20 23:49:28ethan smithlinkissue40280 messages
2021-05-20 23:49:27ethan smithcreate