Should a service worker be able to block with shared memory APIs?

[annevk]

Or in JavaScript-speak, should we set the agent's [[CanBlock]] field to true or false. I need an answer for whatwg/html#2521.

I sort of think false might be better, but I don't really know the use cases and dedicated and shared workers will have it set to true.

[mkruisselbrink]

Since we've been trying to keep all blocking APIs out of service workers I'd say that yes, service workers should not be able to block with shared memory APIs either.

[mfalken]

cc @slightlyoff @jakearchibald

Chrome is likely shipping SharedArrayBuffer soon and Chrome needs to decide whether to ship Atomics on service worker. @jeisinger points out on https://bugs.chromium.org/p/chromium/issues/detail?id=711809 that disabling Atomics means disabling WebAssembly on service worker.

Are we OK with this? As I wrote on the bug, since service worker is not designed for heavy synchronous tasks, I think I'm OK with it, though I may be short-sighted here. Of course it's easier to loosen the restrictions later if needed, than to go the opposite direction.

[jeisinger]

not that I asked whether that amounts to disabling wasm - I don't know how much wasm depends on atomics

[annevk]

1. Once nested workers are supported folks can just use those (if it indeed disables WebAssembly).
2. Potentially blocking on fetches seems quite bad and best avoided altogether. Same as blocking on the main thread.

[mfalken]

not that I asked whether that amounts to disabling wasm - I don't know how much wasm depends on atomics

Ah, I took that to be a rhetorical question :) Sorry. I don't know the answer either.

[asutherland]

FWIW, Firefox's WASM implementation does not seem to be contingent on shared memory and atomics being enabled. Specifically our WASM support flag doesn't care and constructor control seems to treat them orthogonally. @lukewagner, care to weigh in more authoritatively?

[lukewagner]

Right now the atomics are only just being proposed so it's not an issue we're dealing with yet. Looks like @lars-t-hansen just brought up this question in that PR. I would think that we'd just have the wait and wake opcodes trap (throw a WebAssembly.RuntimeError) if !AgentCanSuspend. WebAssembly wouldn't be disabled, though.

[lars-t-hansen]

The way JS does this is that Atomics.wait throws if the agent's [[CanBlock]] flag is false. That flag is currently set at thread creation. How the flag's value is chosen is embedding-specific. In the web space it is currently chosen by a static policy that takes into account only the thread type. In Firefox the value is true for dedicated workers (those created with new Worker in JS) and false for all other threads, including ServiceWorker and SharedWorker threads. (In Firefox those worker types can have nested dedicated workers, and the flag is true for those nested workers.) The reason it is false for SharedWorker and ServiceWorkers is mainly that I decided to be conservative when I wrote that code, until we could get around to discussing it properly. Which we are now doing :)

Atomics.wake does not inspect the [[CanBlock]] flag, and it must not, because it is highly desirable that a thread that cannot itself block can still wake up other threads that have blocked.

Other atomic operations (load, store, add, sub, and, or, xor, exchange, compareExchange, isLockFree) are not affected by [[CanBlock]], they are always enabled. Apart from isLockFree they can only be used on SharedArrayBuffer instances.

In every thread type, the Atomics namespace and the SharedArrayBuffer constructor are available in the thread's global object(s) independently of the value the thread's [[CanBlock]] value.