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
👋 Hello again. It turns out that, in our use case, we don't fully control the workers so we don't always have the chance to cleanly tear down thread-specific space with __wbindgen_thread_destroy.
Proposed Solution
The bare minimum would be to expose __stack_alloc together with __tls_base and accept explicit arguments for those parameters in __wbindgen_thread_destroy. That way, a "leader" thread could perform the tear down (acting like a sort of scheduler).
Alternatives
Do nothing. This goes deeper and deeper into accommodating thread-related use cases without guarantees of stability and no clear prospects on how Rust+Wasm+threads should/could look like.
The text was updated successfully, but these errors were encountered:
Motivation
👋 Hello again. It turns out that, in our use case, we don't fully control the workers so we don't always have the chance to cleanly tear down thread-specific space with
__wbindgen_thread_destroy
.Proposed Solution
The bare minimum would be to expose
__stack_alloc
together with__tls_base
and accept explicit arguments for those parameters in__wbindgen_thread_destroy
. That way, a "leader" thread could perform the tear down (acting like a sort of scheduler).Alternatives
Do nothing. This goes deeper and deeper into accommodating thread-related use cases without guarantees of stability and no clear prospects on how Rust+Wasm+threads should/could look like.
The text was updated successfully, but these errors were encountered: