Struct ScState 

pub(crate) struct ScState {
    pub(crate) backend: u8,
    pub(crate) cursor_ref: bool,
    pub(crate) controls: Option<Arc<Controls>>,
    pub(crate) starting: Option<Arc<Controls>>,
    pub(crate) handle: Option<JoinHandle<()>>,
    pub(crate) cap_thread_id: Option<ThreadId>,
    pub(crate) encode_thread_id: Option<ThreadId>,
    pub(crate) encode_tid_rx: Option<Receiver<ThreadId>>,
    pub(crate) deliver_handle: Option<JoinHandle<()>>,
    pub(crate) deliver_thread_id: Option<ThreadId>,
    pub(crate) wl_display: u32,
    pub(crate) err: Option<Arc<Mutex<Option<String>>>>,
}

Mutable per-capture state behind ScreenCapture’s mutex: the active backend, the live X11 controls and thread handle, and the capture / encode thread ids used to detect a re-entrant stop.

Fields

backend: u8

0 = idle, 1 = X11, 2 = Wayland.

cursor_ref: bool

This capture holds one reference on the shared X11 cursor monitor. Set in the same locked section as backend = 1 and TAKEN in the same locked section a stop reads the backend, so acquire/release pair exactly per capture — inferring the reference from backend alone would let a stop that interleaves with a start release a reference not yet taken (leaking the monitor once the acquire lands). The GIL happens to serialize that window today; the pairing must not depend on it.

controls: Option<Arc<Controls>>

starting: Option<Arc<Controls>>

The controls of an X11 capture whose threads already run while start_capture has not published it: its first frames can reach a consumer before the start returns, and what that consumer asks for in reply (a lost frame, a key frame, a rate) has to reach the capture. A stop or a newer start in that window ends that capture, which is then never published.

handle: Option<JoinHandle<()>>

cap_thread_id: Option<ThreadId>

encode_thread_id: Option<ThreadId>

The internal encode thread’s id, so a re-entrant stop arriving on it is detected and doesn’t try to join a chain that includes itself.

encode_tid_rx: Option<Receiver<ThreadId>>

Handshake receiver kept when the bounded start-time wait for the encode thread id lapsed (slow X11 setup precedes the encode-thread spawn): the id is late-resolved from here on demand, so the re-entrant-stop guard still recognizes the encode thread — with encode_thread_id stuck at None, a stop from inside the delivery callback would join the capture thread, which joins the encode thread (the caller), a deadlock cycle. The id send strictly precedes any callback running on that thread, so a try_recv at stop time cannot miss it.

deliver_handle: Option<JoinHandle<()>>

Delivery thread: owns the GIL-bound Python callback so encode(N+1) never serializes behind deliver(N). Joined on stop; a re-entrant stop from inside the callback (which runs on this thread) must detach instead of self-joining.

deliver_thread_id: Option<ThreadId>

wl_display: u32

The Wayland display id this instance’s capture is bound to (backend == 2).

err: Option<Arc<Mutex<Option<String>>>>

The X11 capture thread’s exit error (backend == 1): the thread records why it died mid-run here, so capture_state can report it instead of the error scrolling past in a single stderr line. None while healthy.

Implementations

impl ScState

pub(crate) fn x11_controls(&self) -> Option<Arc<Controls>>

The X11 controls a request reaches: the published capture’s, else those of one still starting.