(Edited)

Shipping resab ships threads because there's no longer any compile-time flag that controls threads. Thread ops are gated on shared memory being present, which is gated on the pref, which is on-by-default (with resab). Thus we are de facto shipping threads, and this is fine: it's been shipped in Chrome for a long time even if it's still phase 2 and is de-facto on the web and in its final form. The rest is just bookkeeping.

We still need to attend to some last-minute tasks (see blocking bugs).

Re arm64, we want Cranelift support before we can enable this. On the other hand, resab is not riding the trains on Android yet, so Cranelift support would benefit arm64 systems "other than Android", eg, upcoming macOS devices + linux distros + (marginally) Win10 arm64 devices.

I misremembered how the threads ops are configured. They are always present, at the moment, there is no moz.configure flag. But they may only be used if the memory is shared (we check this during opcode reading), and a shared memory can only be constructed if the correct pref if flipped in about:config. However, bug 1619196 changes that logic because it allows the thread ops to be used always; i'm not sure what the fallout is.

How does this differ from bug 1389458?

(In reply to Lars T Hansen [:lth] from comment #2)

I misremembered how the threads ops are configured. They are always present, at the moment, there is no moz.configure flag. But they may only be used if the memory is shared (we check this during opcode reading), and a shared memory can only be constructed if the correct pref if flipped in about:config. However, bug 1619196 changes that logic because it allows the thread ops to be used always; i'm not sure what the fallout is.

Bug 1648755 introduces proper gating for thread ops on the pref. Then bug 1619196 allows thread ops to be used on non-shared memories. These changes compose properly, ie, a thread op on any kind of memory will be rejected if the pref is off.

With this change, simply flipping the pref will enable wasm thread ops, meaning that wasm thread ops will ride along with resab.

IMO the resab intent-to-ship was not real clear about wasm thread ops, and I will follow up to that with a clarification. A completely separate intent-to-ship is not really appropriate since wasm thread ops ship along with resab.

I've completed the documentation on MDN about this; see https://github.com/mdn/sprints/issues/3428#issuecomment-655053796 for details.

Let me know if you think this needs anything else; thanks!