Skip to main content

Module actor

lattice_runtime

Module actor 

Source
Expand description

DocumentActor – the tokio task that owns one document’s writable state (DESIGN.md §5.7, §5.6.8).

§Responsibilities

  1. Exclusive ownership of one [lattice_core::Document]. No other code path holds a &mut Document; mutations arrive as ActorMsg variants on the bounded mailbox.
  2. Snapshot publish after every committed mutation. The actor builds a DocumentSnapshot from the post-commit state and writes it to the PublishedSnapshot cell with store_release semantics.
  3. Unbounded mailbox – audit slice 6 / H3. The mailbox was originally bounded with a try_send -> Busy path for callers; in practice, App-side apply_edit_blocking discarded Busy silently and bursts could desync the buffer from what the user typed. Unbounded eliminates the silent-drop class entirely; queue depth bounds itself by edit rate × actor-stall-duration (typing is human-paced).
  4. Graceful shutdown – when every crate::RopeDocumentHandle is dropped the mailbox closes; the actor’s recv loop exits naturally.

§Why one task per document, not a thread

Documents are I/O-bound (file save/open, future LSP attribution); a tokio task is the right granularity. The LocalSet complexity of “stay on one thread” isn’t needed because Document is Send. Across cores the actor still has exclusive logical ownership – only one task handles any given document.

§Why the actor builds the snapshot, not the handle

Snapshot publish happens inside the actor’s task, after the mutation. Doing it on the handle side would race with concurrent readers and miss the publish-before-respond ordering required by the §5.6.8 acquire/release contract.

Structs§

AppliedEdit
What an apply_edit produced. The caller uses this to log change events and to construct an inverse Edit for the undo stack.
DocumentActor
The actor task. Constructed by crate::spawn_document.