JS API: clarify refreshing of buffers

Bắt đầu với phần “Grow the memory buffer” được liên kết trong đề xuất WebAssembly Threads JS API và so sánh cách diễn đạt của phần này với hành vi của nhiều agent được mô tả ở đây. Xem xét cách việc mở rộng bộ nhớ dùng chung, làm mới buffer, mở rộng zero-page và danh tính đối tượng được thể hiện trong cuộc thảo luận hiện tại. Công việc được xem là hoàn tất khi văn bản đặc tả định nghĩa rõ ràng hành vi có thể quan sát liên quan và loại bỏ sự mơ hồ đối với các triển khai như 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.