Shu-yu Guo

To wit, it seems very, very problematic to shrink SABs in-place. Doesn't seem so bad to shrink ABs in place?

> It seems like that might be desirable. Even if it causes some performance headaches... Seems pretty reasonable to me to say that multiple threads witnessing the length be synchronizing....

Within one thread your semantics are constrained by agent-order anyways (or program order as it's normally known), which is stronger than synchronizing seqcst events.

I think I'd have to see the particular example you're thinking of. I don't know what synchronizing accesses in a single thread means. In my mind there shouldn't be any...

Ah, I see. You mean "synchronizing" in the sense of the AB/SAB length vs the backing store length going out of sync. I agree with @conrad-watt's assumption: that we're working...

Rediscovering problems that came up the first time something like this was talked about at Mozilla with asm.js: growable `ArrayBuffer`s unfortunately isn't enough. The various TypedArray views' lengths would also...

> With a synchronous event, any code that potentially allocates (and therefore potentially grows memory) can potentially run JS, which can then do basically anything, including re-enter Wasm again. Most...

> Would this solve the problem? I think it would for the wasm use case but sets an undesirable precedent. It would encourage further divergence between wasm and JS on...

"Perform the expansion of", maybe?

Oh I see, you were thinking of the thing HTML does. I'm fine with either ! or special prose forms so long as it's all autolinked, which I'm sure it...