Re: [whatwg/encoding] New TextDecoder.decode() API needed for Wasm multithreading (#172)

> Are we _really_ relying on the compilers we use to write DOM-side code not optimizing too hard on the assumption that memory doesn't change from underneath us in cases where it would be UB for it to change underneath us?

Yes and no.  Currently our DOM code can't extract the buffer pointer without extracting a sharedness flag at the same time, and in some(*) cases where it does that we assert that the sharedness flag is false and don't touch the memory.  We are aware that if it did touch that memory it would be UB.

The plan is to remedy this by using UB-safe primitives for accessing shared memory, see https://bugzilla.mozilla.org/show_bug.cgi?id=1225033.  In this case, DOM would have (as the JS engine already has) two code paths, one for known-unshared memory and one for possibly-shared memory, where in non-perf-critical cases we can just use the latter.  Every DOM API that can handle shared memory will have to be adapted to greater or lesser extent to deal with that reality.

Also see long comment in dom/bindings/TypedArray.h.

(*) When the SAB code landed I believe I handled all the cases in DOM at the time by either disallowing shared memory (error out) or by using UB-prone code, but I may have missed some spots and/or DOM may have grown in the mean time and/or code I wrote may have since been rewritten. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/encoding/issues/172#issuecomment-462254977