Home / Companies / Superset / Blog / Post Details
Content Deep Dive

The Terminal That (Almost) Never Dies: Building a Persistent Terminal Daemon for Electron

Blog post from Superset

Post Details
Company
Date Published
Author
Avi Peltz
Word Count
947
Company Posts That Month
3
Language
English
Hacker News Points
-
Post removed?
No
Summary

Superset's integrated terminal is designed to survive app restarts, eliminating the inconvenience of losing progress due to frequent updates or app crashes. Initially, tmux was considered for terminal persistence, but its limitations, such as additional dependencies and incompatibility with Windows, led to the development of a custom solution involving a detachable daemon architecture. This architecture separates terminal management into three process layers, allowing the Electron app to act as a client for the terminal daemon, facilitating session continuity across app restarts, multiple windows, and crash recovery. Communication between the main process and daemon is handled via newline-delimited JSON over Unix domain sockets, with a protocol that prevents head-of-line blocking by splitting communication streams. The terminal sessions can undergo states of creation, attachment, survival, and restoration, aided by disk history for cold restoration in cases of daemon crashes. The system also implements multi-level backpressure to manage fast terminal output effectively, and a headless xterm.js emulator maintains accurate session snapshots and terminal mode tracking. Lessons learned include the importance of protocol versioning, sticky caching to handle React's StrictMode double-mounts, and concurrency limits to prevent overwhelming the daemon. Future developments may extend the abstraction boundary to cloud backends, allowing seamless integration with remote terminal sessions.

Trends Found in this Post

No tracked trend matches for this post yet.

Use This Data

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.