* perf(plugins): run scheduled updates off the render thread
plugin update() executed inline in the render loop — execute_update's
internal thread.join(timeout=30) blocked it, so one slow plugin HTTP
fetch froze scrolling for the whole fetch (up to 30s; DNS-retry storms
made this a regular occurrence on flaky networks).
Scheduling stays on the render thread and keeps every existing gate
(enabled, circuit breaker, can_execute, interval); due updates are now
enqueued to a single background worker (serialized — same one-at-a-time
execution as before, no thundering herd). RUNNING is set at enqueue so
can_execute blocks re-entry alongside the pending-set dedup.
Per-plugin locks make the old implicit update/display no-overlap
guarantee explicit: the worker holds the plugin's lock through its
update; the display side try-locks and, when the plugin is mid-update,
holds the last frame for that iteration — reported as success so a
mid-update skip never advances the rotation. Unlike before, the
guarantee now also holds across the post-timeout window (previously the
lingering update thread overlapped display()). Deadlock-free by
construction: the worker takes one lock; display never blocks.
Timeout semantics unchanged (lingering daemon thread documented).
Kill switch: plugin_system.synchronous_updates: true restores the
inline path.
8 new concurrency tests (non-blocking scheduler, overlap assertion
under a hammering display loop, lock release on failure/timeout paths,
dedup, kill switch); 4-min devpi soak clean (updates completing,
rotation advancing, no stuck RUNNING states).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FqzC1nzTWL4kaqgMaQZFam
* fix(plugins): fix skipped-frame health/force_change tracking, config validation, and lock-lifetime gaps in async updates
Addresses PR #407 review findings:
- display_controller: only clear force_change / record health success
when display() actually ran this frame, not when the frame was skipped
because the plugin's lock was busy (a skip must preserve a pending
mode-switch force_clear).
- plugin_manager: replace bool() coercion of synchronous_updates with
explicit isinstance validation of plugin_system/synchronous_updates,
failing safe to synchronous mode (with a logged reason) on malformed
config instead of silently defaulting to async.
- plugin_manager: _update_worker_loop now acquires the plugin lock before
looking up its instance and re-checks under the lock, so an unloaded
plugin's lifecycle state is never resurrected to ENABLED.
- plugin_manager + display_controller: move lock ownership (and, for
updates, RUNNING/pending lifecycle bookkeeping) into the actual update()/
display() call itself rather than the timeout-wrapped caller, so the
lock stays held for the real operation's duration even after
PluginExecutor's own join(timeout) elapses and a lingering daemon thread
keeps running in the background.
- DisplayController.cleanup() now stops the update worker before tearing
down display/cache resources; stop_update_worker() logs when the join
times out instead of failing silently.
- test_async_plugin_updates: rewrite test_unloaded_while_queued_is_harmless
to exercise the public unload_plugin() lifecycle (via a deterministic
blocker) instead of deleting pm.plugins directly, and add a regression
test proving the plugin lock stays held through PluginExecutor's own
timeout while the real update() call is still running.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KEZK1P1Q1fu5pcuVrkrCFZ
---------
Co-authored-by: Chuck <chuck@example.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
