-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Quesitons about wasi_thread_spawn
semantics
#13
Comments
as i couldn't find a way to determine them reliably, i made them explicitly specified by an embedder for my runtime. |
I don't think the "multiple linked modules" story is completely figured out. I think this question is similar to the dilemma that wasi-threads faces when attempting to use it in the component model paradigm.
I believe that is correct; e.g., in Wasmtime the linking happens again for each new thread instantiation. |
@yamt, can we close this now? |
questions are answered. it seems there is no plan to decide behavior with multiple modules in near future. closing. |
reopening because it's a real problem, not just a question. |
the description of
wasi_thread_spawn
says:it isn't obvious to me which module "the module" here is when multiple modules are involved.
for example, if module A calls a function imported from module B and the function calls
wasi_thread_spawn
, which module is it?also, does
instantiate the module again
imply that an engine needs to keep an equivalent of wasm-c-apiwasm_extern_vec_t
or "import object" (i meanimportObject
argument ofWebAssembly.instantiate
) for possiblewasi_thread_spawn
operations?The text was updated successfully, but these errors were encountered: