Blocking the main thread in web embedding

[binji]

The current proposal does not mention it, but to match behavior of JS Atomics.wait, we should probably allow the embedder to trap when executing i32.wait or i64.wait on main thread. Thoughts?

[lars-t-hansen]

Based on all the feedback I got during the time we worked on the ES spec, I judge it as extremely unlikely that browsers will allow the main thread to block, regardless of what the wasm spec says. Before somebody says "oh, then people will just busy-wait", busy-waiting will usually deadlock the browser because the main thread frequently performs tasks on behalf of other threads in the system. I've concluded that people may try to busy-wait, but they will quickly be cured of the habit. (Hence the proposal for the non-blocking wait currently before the ecma committee).

A more interesting question perhaps is whether a thread should be allowed to ask whether blocking will work on the current thread, this introspection is missing from ES but is less interesting there since the main thread JS environment is so different and can easily be used as a proxy for that functionality.

The alternative to trapping is to return a not-allowed value, I guess. Not sure how useful that is.

[binji]

(Hence the proposal for the non-blocking wait currently before the ecma committee).

Interesting... this is relatively straightforward to do in ES, but is weird in WebAssembly. I could imagine something like:

i32.wait_async <func index>

But that seems very unlike anything else we have currently.

[lars-t-hansen]

Yes, I doubt you want the wait_async functionality for wasm, and definitely not now. For wasm it'd be like a deep coroutine yield; speccing that would take us far afield...

[lars-t-hansen]

I just want to reiterate that while the writeup of this issue in the text for the May 2017 meeting states "This [ie nonblocking main thread] was required for the ES spec," the issue really was browser implementations. ES does not have a notion of a main thread. Browser engineers I talked to stated flatly that blocking on the main thread simply would not work, and we should have no reasonable expectation that we can force this issue.

[binji]

Yes, this is just clumsy wording on my part. I just meant that the ES spec refers to [[CanBlock]], and we should match.

[binji]

We agreed in the CG meeting that there will be a property on the host (similar to the ES spec [[CanBlock]]). If this property does not allow the agent to suspend, then executing i32.wait or i64.wait will trap.

[kettle11]

Before somebody says "oh, then people will just busy-wait", busy-waiting will usually deadlock the browser because the main thread frequently performs tasks on behalf of other threads in the system. I've concluded that people may try to busy-wait, but they will quickly be cured of the habit.

@lars-t-hansen I would like to note that nearly 6 years after this assertion both emscripten and the Rust ecosystem still rely on busy waiting as a workaround. They were not quickly cured of the habit.

Given this reality is there any hope of revisiting the limitation of not being able to block on the main thread?