Re: [w3c/ServiceWorker] Should a service worker be able to block with shared memory APIs? (#1115)

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.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1115#issuecomment-295133986