Struct salsa::Runtime

pub struct Runtime<DB: Database> { /* fields omitted */ }

The salsa runtime stores the storage for all queries as well as tracking the query stack and dependencies between cycles.

Each new runtime you create (e.g., via Runtime::new or Runtime::default) will have an independent set of query storage associated with it. Normally, therefore, you only do this once, at the start of your application.

Methods

impl<DB> Runtime<DB> where
    DB: Database, 

pub fn new() -> Self

Create a new runtime; equivalent to Self::default. This is used when creating a new database.

pub fn storage(&self) -> &DB::DatabaseStorage

Returns the underlying storage, where the keys/values for all queries are kept.

pub fn snapshot(&self, from_db: &DB) -> Self

Returns a "forked" runtime, suitable for use in a forked database. "Forked" runtimes hold a read-lock on the global state, which means that any attempt to set an input will block until the forked runtime is dropped. See ParallelDatabase::snapshot for more information.

Warning. This second handle is intended to be used from a separate thread. Using two database handles from the same thread can lead to deadlock.

pub fn next_revision(&self)

Indicates that some input to the system has changed and hence that memoized values may be invalidated. This cannot be invoked while query computation is in progress.

As a user of the system, you would not normally invoke this method directly. Instead, you would use "input" queries and invoke their set method. But it can be useful if you have a "volatile" input that you must poll from time to time; in that case, you can wrap the input with a "no-storage" query and invoke this method from time to time.

pub fn sweep_all(&self, db: &DB, strategy: SweepStrategy)

Default implementation for Database::sweep_all.

pub fn id(&self) -> RuntimeId

The unique identifier attached to this SalsaRuntime. Each snapshotted runtime has a distinct identifier.

pub fn active_query(&self) -> Option<DB::DatabaseKey>

Returns the database-key for the query that this thread is actively executing (if any).

pub fn is_current_revision_canceled(&self) -> bool

Check if the current revision is canceled. If this method ever returns true, the currently executing query is also marked as having an untracked read -- this means that, in the next revision, we will always recompute its value "as if" some input had changed. This means that, if your revision is canceled (which indicates that current query results will be ignored) your query is free to shortcircuit and return whatever it likes.

This method is useful for implementing cancellation of queries. You can do it in one of two ways, via Results or via unwinding.

The Result approach looks like this:

• Some queries invoke is_current_revision_canceled and return a special value, like Err(Canceled), if it returns true.
• Other queries propagate the special value using ? operator.
• API around top-level queries checks if the result is Ok or Err(Canceled).

The panic approach works in a similar way:

• Some queries invoke is_current_revision_canceled and panic with a special value, like Canceled, if it returns true.
• The implementation of Database trait overrides on_propagated_panic to throw this special value as well. This way, panic gets propagated naturally through dependant queries, even across the threads.
• API around top-level queries converts a panic into Result by catching the panic (using either std::panic::catch_unwind or threads) and downcasting the payload to Canceled (re-raising panic if downcast fails).

Note that salsa is explicitly designed to be panic-safe, so cancellation via unwinding is 100% valid approach to cancellation.

Trait Implementations

impl<DB> Default for Runtime<DB> where
    DB: Database, 

fn default() -> Self

Returns the "default value" for a type.

impl<DB> Debug for Runtime<DB> where
    DB: Database, 

fn fmt(&self, fmt: &mut Formatter) -> Result

Formats the value using the given formatter.