Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TransactionMut: extract state into separate struct #435

Open
Horusiath opened this issue May 11, 2024 · 0 comments
Open

TransactionMut: extract state into separate struct #435

Horusiath opened this issue May 11, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@Horusiath
Copy link
Collaborator

Horusiath commented May 11, 2024

Currently most of the bindings (yrb, ypy, ywasm) only make use of TransactionMut given single threaded nature of their environments. However TransactionMut comes with its own cost: it initializes additional state, which upon commit must be checked through, even it transaction itself didn't made any modifications.

Aside of that we also have a WriteTxn which is an incomplete trait over TransactionMut: in practice we cannot really use it and instead rely on TransactionMut directly in many places.

The proposal here is to split TransactionMut contents into two parts:

  1. mut reference to Store
  2. Option<TransactionState> which is None by default.

The purpose of TransactionState is to keep all of the data related to modifications made by transaction. Upon commit this filed can be reset to None, making a single transaction to be able to do multiple commits. If on commit this field was already None then we don't even need to perform all of the transaction steps.

For ergonomics, we can use WriteTxn in order to make access-is-initialization pattern:

trait WriteTxn: ReadTxn {
  /// Split transaction body into store and state. If state was not initialized,
  /// initialize it and return mutable reference.
  fn split_mut(&mut self) -> (&mut Store, &mut TransactionState);
  
  /// Commit transaction. Reset its state.
  fn commit(self);
}

This would require quite significant rewrite, but it would also allow us to make independent writeable transactions that could carry over some additional state like JavaScript objects etc.

@Horusiath Horusiath added the enhancement New feature or request label May 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant