Does Rust CDK provide same request-processing-model and delivery guarantees as Motoko?

Developers
1

Hey,

I want to know if there are some big differences between Rust CDK and Motoko in request-processing/inter-canister-calls/memory-management/… .

  • Are requests (update-calls) in CDK processed single threaded as in Motoko and queries multi-threaded?
  • Are all changes to memory/variables discarded after a query call in CDK as in Motoko?
  • Are all changes to memory/variables not visible to parallel query calls in CDK as in Motoko (no dirty reads)?
  • Are all changes to variables get visible/stored permanently only after an await call (in update call) in CDK as in Motoko?
  • Are all changes to variables get rolled-back to previous state (where last await was called) when the canister traps in Rust CDK as in Motoko?
  • What is the equivalent of trap (state will be rolled back) and throw (state will not be rolled back) from Motoko to Rust CDK?
  • Will the state in Rust CDK be automatically stored as stable memory (ic_cdk::storage) or is it expected to call ic_cdk::storage::stable_save and if yes, then when (pre_upgrade() or in every update-call)?
  • Does Rust CDK have the same message delivery guarantees in inter-canister-calls as Motoko (every call get exactly a single reject or a single reply)?
  • Does orthogonal persistence also apply to Rust CDK or is it something exclusive in Motoko?
  • If there are some other big differences in Rust CDK an Motoko in request-processing/memory-management or other guarantees, then I would be glad to hear more about them.

Thanks

4 Likes