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

We just spent a bit of time discussing this in a breakout at the TAG face-to-face meeting.

Given that this is a space that the relevant TC39 folks have a lot more expertise in than the TAG does, it's not clear how much we're going to be able to add.

Our current assumption is that this is mainly going to be used by (a) JavaScript or WebAssembly as a compilation target for code written in other languages or (b) low-level libraries written by a very small number of people.  Code dealing with mutable shared state is very difficult to write, which is why the Web's model for multithreaded code emphasizes workers, and we expect that workers will continue to be the main emphasis.

We had a brief discussion about `SharedArrayBuffer` not being transferable, and agree that aspect of the design makes sense.  We note that this means that some code that works with `ArrayBuffer` no longer works with `SharedArrayBuffer`, but that's probably a good thing since converting code from copying to sharing requires very careful consideration.

One of the interesting pieces is that this introduces the possibility of deadlocks into the Web platform.  We're curious what the plan for handling deadlocks is.  Is there going to be some deadlock detection mechanism, or is it the plan simply to treat deadlocks like a tab crash, or is that something that's going to be left more open to implementations?

Thanks for bringing this up for TAG review.  I think we're nearly ready to close this issue, although we'd be interested to hear feedback on deadlocks.

-- 
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-298149776