You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
wasi requires calling initialize() or start() after instantiating wasm and requires that memory is exported from wasm, but this doesn't work in multithreaded scenario (wasm32-wasi-threads target).
With wasi threads, we need to provide wasm memory created in JavaScript (new WebAssembly.Memory({ shared: true })) in main thread, and send the memory to child thread to instantiate wasm again in child thread, and it is unnecessary (and will cause error) to call initialize() or start() in child thread. So normal usage of WASI doesn't work in child thread. But we still need an "initialized" WASI instance in child thread.
Currently I'm using cloned instance object and Proxy to workaround this problem. Is there any possibility to handle this in future Node.js API change?
It seems there has been no activity on this issue for a while, and it is being closed in 30 days. If you believe this issue should remain open, please leave a comment.
If you need further assistance or have questions, you can also search for similar issues on Stack Overflow.
Make sure to look at the README file for the most updated links.
It seems there has been no activity on this issue for a while, and it is being closed. If you believe this issue should remain open, please leave a comment.
If you need further assistance or have questions, you can also search for similar issues on Stack Overflow.
Make sure to look at the README file for the most updated links.
Details
wasi
requires callinginitialize()
orstart()
after instantiating wasm and requires that memory is exported from wasm, but this doesn't work in multithreaded scenario (wasm32-wasi-threads
target).With wasi threads, we need to provide wasm memory created in JavaScript (
new WebAssembly.Memory({ shared: true })
) in main thread, and send the memory to child thread to instantiate wasm again in child thread, and it is unnecessary (and will cause error) to callinitialize()
orstart()
in child thread. So normal usage ofWASI
doesn't work in child thread. But we still need an "initialized"WASI
instance in child thread.Currently I'm using cloned instance object and Proxy to workaround this problem. Is there any possibility to handle this in future Node.js API change?
Node.js version
18.14.0
Example code
https://github.com/toyobayashi/emnapi/blob/9bc69c52bc8d582c92acc754ea6a0050572d871b/packages/core/src/load.js
loadNapiModuleImpl
Operating system
macOS 13.2
Scope
code? or runtime?
Module and version
require('node:wasi').WASI
The text was updated successfully, but these errors were encountered: