Generated JS binding is not thread-safe

[d3lm]

Describe the Bug

I am working on a Rust project that we compile to wasm32 which uses atomics. The compiled wasm is then used in a browser by multiple web workers. I was seeing strange issues with return values from different workers where the return values got mixed up, e.g. worker 1 received a return value from another worker. After drilling into this I found that the JS binding that is generated by wasm-bindgen is not thread-safe. In particular, I ran into a lot of issues when returning Option's to JS. The generated code for this is the following:

var r0 = getInt32Memory0()[8 / 4 + 0];
var r1 = getInt32Memory0()[8 / 4 + 1];

When using synchronization primitives the order in which threads / workers are unlocked is not always guaranteed, and that's why this can easily mix up return values because all threads use the same stack space for return values.

Possible Solution

After talking to @alexcrichton, one possible solution could be to increment a stack pointer per thread and have each thread allocate a unique stack space (a thread-local area).