Re: [w3ctag/design-reviews] SharedArrayBuffer + Atomics (#165)

Indeed I think that the only situation in which we *must* have `[[CanBlock]]` equal to `true` is in dedicated workers.  The recent modifications of the HTML spec to accomodate this feature, as @binji notes, also allows it in shared workers (not yet implemented in Firefox), but not in service workers, nor in the main thread nor elsewhere (if there is any elsewhere).

We discussed at one point whether the `Worker` constructor should even take a flag specifying the value of this flag, mainly to force the browser to allocate a dedicated thread to the worker if the flag was `true` (as opposed to sharing a thread among workers or delaying the start of a worker, as Firefox did (does?)), but this fell by the wayside as the worker spec was updated and we decided browsers could always afford dedicated threads for their workers.

I think that it is possible in principle to have automatic, no-false-positives deadlock detection but that it will be almost worthless in practice given that nearly always, some agent in the cluster will be nonblocking and have access to the shared memory, and can therefore in principle always be available to wake some waiting agent.  It is only in the situation where all the nonblocking agents have dropped their last pointers to any shared memory and have run GC to prove that, that we can potentially detect deadlocks among the remaining agents.

The spec arguably provides too little in terms of introspection, though the mechanisms that are provided are so low level, and shared memory is so powerful for inter-agent communication, that it's not hard to imagine building the necessary introspection and deadlock detection facilities in JS.  For example, an agent can account for itself in shared memory before going into a wait, thereby allowing the main thread or a dedicated aux thread to detect whether its agents are deadlocked.  For the same reason, we have no interrupt mechanism - the application is expected to provide one with the appropriate semantics.

I also think that as time goes by we'll see the need for specific abstractions that make it simpler and less error prone to use shared memory, and we'll push those abstractions into specs.  Along those lines, I have one proposal pending here: https://github.com/lars-t-hansen/moz-sandbox/blob/master/sab/waitNonblocking.md

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/165#issuecomment-300400927