Struct PluginHostProcess 

pub struct PluginHostProcess { /* private fields */ }

Manages a plugin running in an isolated process.

Responses are read on a background thread and delivered over a channel, so Self::send_command can wait with a deadline: a hung plugin yields a timeout error (and the child is killed) instead of blocking the host forever, and a crashed helper surfaces as a disconnect error rather than a silent wedge.

Implementations

impl PluginHostProcess

pub fn new( helper_override: Option<PathBuf>, timeout: Duration, ) -> Result<Self, String>

Create a new isolated plugin host process

pub fn set_timeout(&mut self, timeout: Duration)

Set how long to wait for a helper response before declaring a timeout.

pub fn set_slow_command_timeout(&mut self, timeout: Duration)

Set the deadline used for the slow command class — loading a plugin and saving or restoring its state. Never shorter than the per-command timeout.

pub fn discarded_line_count(&self) -> u64

How many lines from the helper were discarded (oversized, over-queued, unparseable or unsolicited). A non-zero count means the helper is putting non-protocol data on the stream — typically a plugin writing to stdout on a platform where the protocol channel cannot be made private.

pub fn send_command( &mut self, command: HostCommand, ) -> Result<HostResponse, String>

Send a command to the helper process and wait (with a deadline) for a response.

Returns an error without blocking indefinitely if the plugin hangs (the child is killed) or the helper has crashed/exited.

A line that does not parse as a response is either a helper that died mid-write — reported as a crash — or noise on the stream, which is dropped so the exchange stays in sync instead of answering every later command with the previous one’s reply. The deadline covers the whole exchange, not each individual line.

One command heals itself: a HostCommand::LoadPlugin that kills the helper is replayed once against a freshly spawned one. A helper that died mid-load holds nothing worth preserving — its load never completed — so the replay is observationally identical to the caller having spawned the helper a moment later, and it absorbs the cold-load crashes some real plugins lose a race to. A timeout is not retried (it already cost a full deadline, and a plugin that hangs while loading will hang again), and no other command is: those run against a helper holding live plugin state that a fresh process would not have.

pub fn is_alive(&self) -> bool

Whether the helper process is still considered alive.

pub fn helper_pid(&self) -> Option<u32>

OS process id of the running helper, if any. Useful for monitoring — and for tests that need to simulate a crash by killing the helper.

pub fn check_process_status(&mut self) -> Result<(), String>

Check if the helper process is still running

pub fn shutdown(&mut self)

Shutdown the helper process

Trait Implementations

impl Drop for PluginHostProcess

fn drop(&mut self)

Executes the destructor for this type.

fn pin_drop(self: Pin<&mut Self>)

🔬This is a nightly-only experimental API. (pin_ergonomics)

Execute the destructor for this type, but different to Drop::drop, it requires self to be pinned.