Lots of work and rethinking went into this one.
Main goal was to keep things safe but allowing multiple threads to read/write to the store.
In the end I decided to provide a higher level API for devs that don't want to deal with having to lock/unlock the store when accessing state and are OK with a small perf hit due to possibly fetching/converting data parts to Dart that might not be needed. When needed they can use the lower level API which is provided as well and sits just below that higher level API
The following are the main points here to support this in a user friendly way.
Message/Reply
using Dart Isolate to be able to post replies to messages
messages include a req_id which is used in replies to correlate them
messages time out in order to alert dev that a reply needs to be posted
replies can be posted from any thread
Multithreaded Store Access
store is accessed via read/write lock
messages obtain a write lock before calling update
Store.raw.runLocked(fn) allows read-locking the store in order to fetch data while preventing writes
read locks thus obtained are counted on the Dart side and is requested from Rust when the lock count goes from 0 to 1 and released when it goes from 1 to 0
higher level Store API does this under the hood and converts all data to Dart classes leaving the dev from having to deal with those details
lower level API still is exposed for perf critical apps in which case the store needs to be locked manually when retrieving data
There is lots more here, but I won't go into too much detail that is easier learned by reading the updated code.
Please consult the store docs to learn more about this new attribute.
LMK if you have any questions. I'm planning to squash+merge this soon as I'm planning to stream building this example app which uses the Message/Reply pattern and includes a multi-threaded aspect of a ticker expiring a Todo
Summary
Lots of work and rethinking went into this one. Main goal was to keep things safe but allowing multiple threads to read/write to the store.
In the end I decided to provide a higher level API for devs that don't want to deal with having to lock/unlock the store when accessing state and are OK with a small perf hit due to possibly fetching/converting data parts to Dart that might not be needed. When needed they can use the lower level API which is provided as well and sits just below that higher level API
The following are the main points here to support this in a user friendly way.
Message/Reply
req_id
which is used in replies to correlate themMultithreaded Store Access
update
Store.raw.runLocked(fn)
allows read-locking the store in order to fetch data while preventing writesThere is lots more here, but I won't go into too much detail that is easier learned by reading the updated code.
Please consult the store docs to learn more about this new attribute.
The application doc talks here about the Message/Reply pattern.
LMK if you have any questions. I'm planning to squash+merge this soon as I'm planning to stream building this example app which uses the Message/Reply pattern and includes a multi-threaded aspect of a ticker expiring a Todo
Fixes: #2
cc @Yatekii