syscall: on wasm, do not use typed array asynchronously
The underlying buffer of a typed array becomes invalid as soon as we grow the WebAssembly memory, which can happen at any time while Go code runs. This is a known limitation, see https://golang.org/cl/155778. As a consequence, using a typed array with one of the asynchronous read/write operations of Node.js' fs module is dangerous, since it may become invalid while the asynchronous operation has not finished yet. The result of this situation is most likely undefined. I am not aware of any nice solution to this issue, so this change adds a workaround of using an additional typed array which is not backed by WebAssembly memory and copying the bytes between the two typed arrays. Maybe WebAssembly will come up with a better solution in the future. Fixes #31702. Change-Id: Iafc2a0fa03c81db414520bd45a1a17c00080b61e Reviewed-on: https://go-review.googlesource.com/c/go/+/174304 Run-TryBot: Richard Musiol <neelance@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Showing
Please register or sign in to comment