wip: shared durable object approach #737
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This provides a possible implementation for a
SharedDurableObject
trait which does not implement the&mut self
pattern but instead implements&self
to allow multiple concurrent borrowers.This then pushes the concurrency problem for durable object access down into field cells, where any standard Rust techniques can then be used to manage mutable field access -
Mutex
/RwLock
/RefCell
etc.The test here uses the
RefCell
approach for mutable fields, where so long as mutable borrows are not held over async points there will never be a panic.While formally we are single threaded, blanket turning off concurrency checks on mutable access may have implications for undefined Rust compiler behaviours. So instead this approach aligns with Rust conventions, even though threaded code is not in play.
I think these idioms should be perfectly comfortable to Rust devs (far more than relaxing mutable behaviours), even if they don't fully apply in this single threaded JS embedding environment it remains closer to the proper way of doing things without much ergonomic cost.