Right now, nuts only works in a single thread. All data is stored in the thread-local storage object NUT. If there are multiple threads (non-web) then there will be multiple such nuts that are completely oblivious of each other.
The idea to be captured by this issue is that there could be multiple nuts that communicate with each other and the work split between them. Activities in different domains could live in different nuts. Messages would be forwarded to all nuts, but the state stored in domains could be kept in a single nut (= single thread).
Once this works on a non-web target, the feature can be extended to work on the web too, using web workers that communicate with the browser API's message passing. This would allow to have easy multi-threading in WASM, even without browser support for SharedArrayBuffer and WebAssembly threads.
Right now, nuts only works in a single thread. All data is stored in the thread-local storage object
NUT. If there are multiple threads (non-web) then there will be multiple such nuts that are completely oblivious of each other.The idea to be captured by this issue is that there could be multiple nuts that communicate with each other and the work split between them. Activities in different domains could live in different nuts. Messages would be forwarded to all nuts, but the state stored in domains could be kept in a single nut (= single thread).
Once this works on a non-web target, the feature can be extended to work on the web too, using web workers that communicate with the browser API's message passing. This would allow to have easy multi-threading in WASM, even without browser support for SharedArrayBuffer and WebAssembly threads.