Module multibuffer_view_task 

MV.1 — the per-plugin actor bridge for multibuffer-view sources.

The picker_task.rs shape, and deliberately so: a dedicated async task owns the plugin’s Store<PluginState> for life (the Store is !Sync), a [ViewCall] crosses an mpsc channel with a oneshot reply, and the Send + Sync MultibufferViewClient serializes calls onto the single- consumer loop. PluginHost::spawn_multibuffer_view_source instantiates the multibuffer-view-plugin world under the plugin’s grant and returns (client, actor); the caller drives MultibufferViewActor::run on its multi-thread runtime (the lib owns no runtime).

This is the fourth actor of this shape (picker, completion, agenda, view). The rule-of-three trigger to generalise the loop over the bindings type has fired, and generalising it is its own refactor rather than a thing to attempt inside the slice that adds the fourth — noted here so the next one does not have to rediscover the count.

Re-exports

pub use crate::lattice::plugin_host::types::MultibufferViewResult;

pub use crate::lattice::plugin_host::types::MultibufferViewSpec;

Structs

MultibufferViewActor

The per-plugin actor: owns the Store + view bindings for the plugin’s whole life and serves calls until every client is dropped.

MultibufferViewClient

The Send + Sync handle the provider holds. Cloning is cheap (an mpsc Sender clone); every clone talks to the same actor / Store, so calls serialize on the single-consumer loop — the guarantee the !Sync Store needs. Dropping the last clone ends the actor loop (teardown).