Consider using wasm threads in the wasm node

[tomaka]

Most of the content of wasm-node at the moment assumes one thread, but we could change that.

[tomaka]

In order to be able to use a SharedArrayBuffer, we need to compile the Wasm with -C link-arg=--import-memory

Then it should be a matter of proper initializing the multiple workers.

And then everything in wasm-node has to be made thread safe.

[tomaka]

Unfortunately, using threads requires workers, and #2498 goes against this idea.

However, we could also for example expose a Client.runThread() function that never returns (unless the client terminates) and runs an additional thread.

[tomaka]

This issue is theoretically feasible, but is rather complicated.

The execution model of the Wasm at the moment is:

• The JS code calls a function on the Wasm (such as init, timer_finished, connection_message, etc.).
• The Wasm then executes either as much as possible if the periodically_yield setting is false, or a little bit if periodically_yield is true.
• As part of the execution, the Wasm calls start_timer, connection_open, etc., which indicates to the JS when to call the next Wasm function.

How to make this multithreading-friendly is kind of complicated.

One the aspects is that, due to browser restrictions, all connections-related functions should only be called from the "main thread".

[tomaka]

Assuming that runThread blocks forever, it would use the atomics Wasm instructions.

What I think we should do is:

• Tasks are split in two categories: tasks that interact with networking (open connections, send messages, etc.) and the others.
• When a networking task gets waken up, "nothing" happens, like is currently the case.
• Before returning control to the JS, the main thread calls advance_execution() like is currently the case. If there is at least one background thread, we only execute the networking tasks. If there is no background thread, we execute all tasks.
• The background threads simply execute the non-networking tasks in a loop, just like a tokio executor would for example do.
• When a task that doesn't interact with the networking gets waken up, it wakes up the background threads (if any is sleeping).