jakmeier / nuts Goto Github PK

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.

Idea:

Allow subscriptions without an activity.

Current Status

With the current API, a subscription can only be created on an activity. This sometimes forces programmers to create a dummy activity to react on a specific message.

Example:

  let dummy = nuts::new_activity(());
  dummy.subscribe(|_: &mut(), msg: &Message| { /*...*/ });

Possible new syntax

  nuts::subscribe(|msg: &Message| { /*...*/ });

Also feasible to add:

  nuts::subscribe_domained(&MyDomain::DomainA, |domain, msg: &Message| { /*...*/ });

Nuts sequentially schedules jobs that are activated by published messages. It is essentially implementing an event loop.

When Nuts is used in the browser, it could potentially use the postMessage() function to schedule tasks on the native event loop.

Before merging a potential implementation, it would be good to assess the performance and size difference.