Threading support

[rth]

Just an issue to track the status on the threading support.

Emscripten has Pthreads support via SharedArrayBuffer capability in browsers. The later got disabled due to Spectre etc vulnerabilities, however,

• a few days ago there was an announcement that threading should work again with WASM in Chrome 70 (https://developers.google.com/web/updates/2018/10/wasm-threads)
• SharedArrayBuffer is available in Firefox since 57 via a config option, but that is disabled by default. The switch to enabled by default can be tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1477743

There also has been some activity in emscripten on this subject lately.

Because of,

If code is compiled with -s USE_PTHREADS=1 and the current browser does not support multithreading, then an exception will be thrown at page load time. It is not possible to build one binary that would be able to leverage multithreading when available and fall back to single threaded when not. For such backwards compatibility, two separate builds must be done, one with -s USE_PTHREADS=1 and the other with -s USE_PTHREADS=0.
(taken from emscripten docs)

I imagine we won't be able to do much until both Firefox and Chrome have it enabled by default in a stable release. Still it might be worth trying to make it work in a WIP PR to see what are the difficulties that could arise. Opening this issue for future reference.

This would also very partially address #144

[pbazant]

Dear pyodide devs, I'd like to start experimenting with the threading support -- our target browser is Chrome anyway (we need web-bluetooth support). Before I delve into the pyodide codebase: How hard should I expect enabling the threading to be?

[rth]

@pbazant I don't have a good understand of much work it would be, but it would be certainly worth trying to build with threading support following emscripten docs and reporting here if you run into any issues :)

Though we likely won't be able to merge it in pyodide until support has been enabled in firefox by default, and it doesn't look like it happened yet.

[gatesn]

Looks like this fails in that Emscripten won't allow us to use dynamic loading and PTHREADS in the same build: emscripten-core/emscripten#3494

[pbazant]

I actually managed to build Pyodide with threads semi-working. I had to change several compilation options. This caused emscripten to remove many symbols, so I had to force it to keep them by listing them all. Maybe there is a cleaner way.
As you say, this is at the cost of not being able to use dynamic loading.
The problem with the threads was that the non-main threads seem to run only when the main thread is running. Data sharing between the threads seemed to work OK, however! It looked like there was some strange business with the non-main thread being blocked on some mutex. Possibly the GIL behaves in a weird way? I will be investigating this in the future. If I manage to make it fully working, I'll share my results. Thank you all for your answers.

[gatesn]

That’s neat - would you be able to push up a branch for me to poke at?

[gcatto]

@pbazant I see you mentioned web-bluetooth above. I have a use case where I am just starting to consider that in combination with Pyodide. Have you gotten anywhere?

[pbazant]

@pbazant I see you mentioned web-bluetooth above. I have a use case where I am just starting to consider that in combination with Pyodide. Have you gotten anywhere?

It's a company project. I think web-bluetooth is usable only from the main thread, so if you run Pyodide in a worker thread (probably a good idea), you must use some communication mechanism between the threads.
Option 1: use postMessage in bith directions(which is tricky because postMessage is tied to the JS event loop and single runPython invocation doesn't yield to the JS loop)
Option 2: use postMessage only to send messages from Pyodide to the main thread but use the Atomics API + SharedArrayBuffer to send data form the main thread to the worker thread (where Pyodide runs).

[pbazant]

We postponed making the threads work and use async/await + asyncio in Pyodide as a temporary solution to concurrency. To use asyncio, we inherited from asyncio.BaseEventLoop and did some tweaking (one has to provide a custom selector implementation).