JS API: clarify refreshing of buffers

Inizia dalla sezione collegata “Grow the memory buffer” della proposta WebAssembly Threads JS API e confrontane la formulazione con il comportamento di più agenti descritto qui. Esamina come vengono rappresentati nella discussione attuale la crescita della memoria condivisa, l’aggiornamento del buffer, la crescita della zero-page e l’identità degli oggetti. Il lavoro è completato quando il testo della specifica definisce esplicitamente il comportamento osservabile rilevante e rimuove l’ambiguità per implementazioni come V8.

Comparing our implementation of this proposal with the spec text, I was surprised to find that the spec for growing a shared memory (https://webassembly.github.io/threads/js-api/index.html#grow-the-memory-buffer) does not at all mention the existence of multiple agents. Since that's a situation that's somewhat tricky to get right, it would be nice for the spec text to be very explicit. I think the text as currently written could be read as "when thread A grows a shared memory, thread B may never realize that this happened", which I guess isn't what was intended.

To illustrate with a concrete example: IIUC, V8 currently refreshes too many buffers. When thread A grows a shared memory, it notifies all other threads referencing the same shared memory that some memory growth has happened (the notification includes no details), and when those threads become aware of that notification, they refresh the array buffers for all shared memories that they know of. Due to the freezing of these buffers, that's unlikely to break any userspace code, but technically it is observable via object identity.
So for both efficiency and spec compliance, I think that implementation should probably be changed to refresh only the buffers associated with the memory that was grown. It is, however, not trivial to identify them by their own length mismatching that of the underlying memory block, because the memory.grow instruction can grow a memory by zero pages. So the obvious fix I have in mind would end up refreshing too few buffers.
To figure out a viable implementation design, it would be nice to have confidence that it actually matches the spec (and hence other implementations), so I would appreciate it if the spec didn't leave as many details to my imagination.