Browsers

[AlexEne]

@sunfishcode raised that this proposal should also specify what browsers are expected to do for the new wasi method(s).

I immagine for browsers nothing would change and they'd do whatever they do today :). I'm just not sure what exactly that is so it needs a bit of investigation.

[penzn]

I imagine for browsers nothing would change and they'd do whatever they do today :).

Yes, I think we had pretty good consensus on that. The way this API can be polyfilled is by starting a worker from thread_spawn, which can be done from either a worker or main thread. This has well-documented limitations and we are going to get those here as well. The good part is that rest of the functionality needed, which will be implemented via atomics would be shared between browsers and standalone runtimes.

[AlexEne]

There is the open question if join should be a API of WASI or a method implemented with the existing atomics. At the moment, the current proposal only adds a thread_spawn, leaving the rest to be implemented in WASM code.

However, there are some genuine advantages of adding join as a WASI method, such as simple implementation on out-of-browser scenarios, less WASM code to get to the devices (so a bit smaller binaries). But that makes it clearly not usable in browsers at least not in the same way as in out-of-browser scenarios, due to its blocking nature.

On the other hand, having it in WASM, it is less work for the VMs to implement (so technically no work is simpler than some simple work -- in the case of a native function :D). That is, once we have an implementation.

[sbc100]

In terms of the browsers I don't think it makes any difference if we build join out of existing atomics to call an import. Anyone targeting the main browser thread will need to take special steps either way.

If you target the main browser thread then all blocking calls, not just pthread_join, but also pthead_mutex_lock or any atomic.wait instructions already need special handling. In emscripten we do this by conditionally busy-waiting (while also warning that this is not advisable!) if we detect we are running on the main thread.

Another way of putting it: If we want to take arbitrary wasm modules that use atomics and run them in the main browser thread then we already require some kind of transform to replace/remove/annotate the atomics.wait instructions within the module so building join on top of atmoics.wait seems fine.

As to whether we should just build it on top of atmoics.wait in userspace, I think that would make sense if it is feasible. I'm not yet convinced it is, but I think our policy should be: if we can reasonably build something userspace, without inventing a new API, then we should.

[sbc100]

BTW, in emscripten we use the posixtestsuite of pthread tests to test conformance:

https://github.com/emscripten-core/posixtestsuite (forked from http://posixtest.sourceforge.net/).

Obviously we have to exclude a good chuck of it that we don't support (e.g a lot of the signal handling stuff):

https://github.com/emscripten-core/emscripten/blob/b2dc6cfad086059bec9b713a8bd0ac313f559fd6/tests/test_posixtest.py#L47-L123

Its certainly helped us find a lot of bugs.

[AlexEne]

+1.
I think we should try it and see how it works and how it behaves then decide on a final design proposal. It's a bit hard to imagine for me at least at this moment.

That's a great suggestion on the test suite!

[sbc100]

BTW, how sure are folks that join can be implemented in user space? I'm think I've convinced myself its possible. @lukewagner you seemed pretty sure?

[lukewagner]

If we can assume the same library implementation controlling both join and thread creation, then it seems to me like join can memory.atomics.wait and the return path of thread creation can memory.atomics.notify.