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
See here for context on this decision, in particular
For example, consider a user wishing to distribute a WebAssembly binary for a C++ library. Say that library uses C++11 atomics internally to achieve thread-safety, but is otherwise agnostic to whether it is used in a single threaded environment or a multithreaded environment. On native platforms a single build of the library can be used in both environments, but due to the validation rules for WebAssembly atomics, the library must be built twice for WebAssembly; once with atomics enabled and once without. Beyond causing extra work for developers, having to produce these separate builds is also a large hole in WebAssembly's portability story.
So I believe the point is to better facilitate static linking of WebAssembly (e.g. see here).
Ah so the summary is that wait/notify may be in the binary but not actually used when in a non-shared environment, and that should be allowed. That makes sense, thanks for the clarification. I think this will be a common question so it could be worth copying something into the overview itself for it.
Currently, wait/notify check whether memory is shared or not at runtime
https://github.com/WebAssembly/threads/blob/main/test/core/atomic.wast#L492
It seems like whether memory is shared or not could always be determined at instantiation time. Is there a reason it needs to be checked at runtime?
The text was updated successfully, but these errors were encountered: