psmux 架构深度剖析Rust ConPTY 如何实现原生多路复用一窗格一 ConPTY 的秘密【免费下载链接】psmuxTmux on Windows Powershell - tmux for PowerShell, Windows Terminal, cmd.exe. Includes psmux, pmux, and tmux commands. This is native High-Performance Tmux designed for Windows in Rust 项目地址: https://gitcode.com/gh_mirrors/ps/psmux一句话概览psmux 是用 Rust 编写的 Windows 原生终端多路复用器Terminal Multiplexer它像 tmux 一样把多个 shell 会话、窗口、窗格pane塞进同一个终端窗口但底层不走 WSL而是直接驱动 Windows 的 ConPTY 伪控制台 API——一个窗格对应一个独立的 ConPTY因此每个窗格里的pwsh、cmd、wsl都是货真价实的 Windows 进程。本文带你从多路复用这个词出发一层层拆开 psmux 的内部结构客户端/服务器如何分工、每个窗格的三个线程各自在干什么、字节如何从你的键盘一路走到屏幕。全程无需编译只要你会读文章就行。为什么原生对 Windows 多路复用很重要在 Windows 上用 tmux 风格的多路复用传统上有三条路各有代价方案Shell 跑在哪里牺牲什么WSL 里跑 tmuxLinux 虚拟机内原生pwsh、cmd、Windows 剪贴板都隔了一层wsl.exeCygwin / MSYS2 下跑 tmuxPOSIX 仿真层 pty 垫片依赖真实控制台的应用如 PSReadLine行为异常性能受仿真层限制psmux真实 Windows 进程 真实 ConPTY无仅 tmux 依赖 Unix 信号的部分做模拟ConPTYPseudo Console是 Windows 10 1511 引入的 API它让一个父进程拥有子进程的整个控制台——键盘输入和屏幕输出都通过两条管道在两者之间流动。psmux 的每个窗格就是用CreatePseudoConsole创建的独立 ConPTY窗格里的 shell 就是一个普通 Windows 子进程只是它的屏幕恰好归 psmux 管。没有 POSIX 仿真没有fork()没有 Unix socket。官方架构文档对此有完整说明docs/architecture.md。客户端/服务器模型关掉窗口会话不死psmux 采用经典的detached server分离式服务器模型——这正是 tmux 的灵魂你执行psmux new-session -s work它派生一个后台进程psmux.exe server -s work没有控制台窗口、标准输入输出全部置空因此能扛住远程桌面断开、任务计划程序关机前的任务终止。psmux attach -t work只启动一个瘦客户端它通过~\.psmux\目录下的注册文件找到服务器然后开始收帧 发按键。关掉终端窗口死掉的只是客户端。会话、所有窗格里的进程原封不动随时可以重新 attach。那客户端怎么找到服务器Windows 没有 Unix socketpsmux 用环回 TCP 四个小文件替代服务器把监听器绑定到127.0.0.1的临时端口见 src/server/mod.rs注册文件内容作用session.key随机认证密钥每次连接必须先发AUTH key否则被拒src/server/connection.rssession.sid会话 ID#{session_id}的稳定身份session.pidpid:创建时间存活锚点防止 PID 复用误判session.portTCP 端口最后写入它的出现就是服务器就绪的信标attach的客户端以 10 ms 轮询一次.port文件一出现就连上——冷启动也就慢一个轮询周期。一个有趣的细节psmux、pmux、tmux其实是同一个程序的三份二进制Cargo.toml 中三个[[bin]]都指向src/main.rs所以你现成的tmux脚本在 Windows 上可以直接运行。一窗格一 ConPTY每个窗格的三线程流水线这是标题里秘密所在。每个窗格在 src/pane.rs 中由三条线程协同工作彼此用缓冲区和条件变量解耦子进程 (pwsh.exe) │ 向自己的控制台写 VT 字节 ▼ ConPTY (conhost / OpenConsole) ── 输出管道 ▼ 读线程 (每次最多读 64 KB绝不碰解析器锁) │ 暂存缓冲区 (Mutex Condvar) ▼ 解析线程 (字节还在到达时按 1 ms 自适应合并) │ 喂给 vt100::Parser屏幕网格 备用屏 滚动历史 ▼ 屏幕状态 ──► 布局快照 JSON ──► TCP 推给所有已连接的客户端 ▲ 写队列线程 ←── 服务器主循环 (按键/粘贴按窗格排队写入 ConPTY 输入管道)读线程纯 I/O从 ConPTY 输出管道一次读最多 64 KB 进暂存缓冲区从不拿解析器锁——所以一个疯狂输出的窗格绝不会拖慢自己。它还顺手直接应答终端颜色查询OSC 4/10/11。解析线程等待条件变量然后以 1 ms 为节拍字节还在来就继续消化自适应合并把字节喂给 vendored 的 crates/vt100-psmux 解析器。解析器持有屏幕网格、备用屏alternate screen、滚动历史history-limit行、SGR 颜色、OSC 8 超链接与 OSC 7 工作目录状态。写队列线程按键和粘贴文本按窗格排队由专用线程写入 ConPTY 输入管道——一个卡死的子进程永远不会阻塞服务器主循环瞬时写错误会被重试而不是丢弃。为什么拆分这么彻底因为多路复用器的命脉是任何单个窗格都不能拖垮全局读、解析、写三条路径各自有界、各自有队列互不持锁等待。字节之旅从按键到屏幕只需几毫秒把两段拼起来一次按键盘→看到回显的完整旅程是输入下行客户端用 crossterm 捕获按键src/client.rs翻译成 tmux 键名C-a、M-Left、S-Enter作为send-key文本行经环回 TCP 发给服务器亚毫秒级。服务器转发主循环把按键投入该窗格的写队列写线程写进 ConPTY 输入管道子进程收到。输出上行子进程把 VT 字节写进 ConPTY 输出管道 → 读线程读出 → 解析线程更新屏幕模型 → 状态标记为 dirty。推送渲染服务器不做定时重绘。一旦有 dirty就把活动窗口所有窗格的可见单元序列化成 JSON 帧dump_layout_json_fast持解析器锁约 1 毫秒推给每个已连接客户端。客户端绘制客户端用 ratatui 风格的 TUI 后端把帧画成窗格内容、边框、状态栏再转发下一批输入。实测数据参考机型Windows 11 PowerShell 7详见 docs/performance.md指标数值一条 CLI 命令往返含启动客户端进程15–25 ms按键到屏幕超出 ConPTY 本身的底噪部分中位数仅约 0.4 ms新窗格显示pwsh提示符热池命中约 100 ms服务器进程内存11 窗口 / 16 窗格约 30 MB注意ConPTY 底噪这个概念conhost 的伪控制台序列化器对每按一次键会拆成两块输出、间隔约 15 ms这是所有ConPTY 使用者包括 Windows Terminal都要付的成本不是 psmux 造成的。ConPTY 直通模式再省一次拷贝在 Windows 11 22H2build 22621上psmux 创建伪控制台时会带上PSEUDOCONSOLE_PASSTHROUGH_MODE标志值为0x8定义于 crates/portable-pty-psmux/src/win/psuedocon.rs。直通模式下conhost 不再把子进程输出重新渲染进自己的屏幕缓冲区再转 VT而是原样转发应用写出的 VT 流。好处有二保留了 conhost 原本会改写的序列光标形状、部分颜色查询并且输出路径上少了一次拷贝。若系统不支持该标志代码会自动降级重建不带直通的伪控制台并记录日志——你也可以用$env:PSMUX_NO_PASSTHROUGH 1手动关闭。热池让慢的东西提前慢完开窗格真正的瓶颈从来不是 psmux而是shell 启动——pwsh光启动就要 200–1000 ms取决于你的 profile。psmux 用两层预热把它藏起来详见 docs/warm-sessions.md热服务器一个隐藏的__warm__服务器提前拉起、配置已加载。new-session通过重命名它的注册文件认领它——冷启动 215 ms 变成热认领约 50 ms。热窗格每个服务器内部常驻一个备用 shell。split-window/new-window直接把备用 shell 交给你同时在后台再拉起下一个备用于是提示符在约 100 ms 内出现。这就是为什么你第一次拆分秒开而连续快速拆分会稍慢——备用 shell 用掉了热池在后台补货。性能纪律让打字在高负载下依然跟手架构之外的几个纪律性设计完整清单见 docs/performance.md技术效果服务器推送渲染非轮询帧在 ConPTY 输出后几毫秒内到达客户端客户端自适应轮询打字时 10 ms / 空闲 16 ms / 粘贴时 1 ms惰性窗格缩放终端窗口变化时只缩放在活动窗口的窗格50 个后台窗口不产生 50 次ResizePseudoConsoleShell 路径OnceLock缓存PATH 查找每个服务器只做一次高于正常的进程优先级psmux 自身的服务器/客户端进程设为above-normal编译打满 CPU 时交互路径不会被饿死Release 构建opt-level 3 全 LTO 单 codegen unit 剥离符号发布版构建参数就在 Cargo.toml 的[profile.release]里可验证。源码导航想继续深挖从这里走路径内容src/main.rsCLI 入口、参数归一化、会话路由、attachsrc/server/mod.rsrun_server监听器、注册文件、主循环、帧推送src/server/connection.rs线协议AUTH、命令解析、各命令处理器src/pane.rsConPTY 派生、读线程、解析线程、写队列src/tree.rs / src/layout.rs窗口/窗格树、布局、帧序列化src/client.rs已连接客户端渲染循环、输入转发、鼠标src/platform.rsWin32控制台模式、进程树、优先级、剪贴板crates/portable-pty-psmuxConPTY 封装含直通模式crates/vt100-psmuxVT 解析器与屏幕模型滚动历史、OSC 7/8延伸阅读docs/features.md完整功能列表、docs/compatibility.mdtmux 命令兼容矩阵、docs/diagnostics.md调试日志与排障。结语三个名字一个秘密回顾一下 psmux 的架构答案一个服务器 一个瘦客户端会话活在分离式服务器里窗口只是取景器一窗格一 ConPTY每个窗格都是独立的原生控制台读/解析/写三线程互不拖累推送而非轮询 热池字节变化几毫秒内上屏shell 启动的慢被提前消化。没有 WSL、没有 POSIX 仿真、没有额外的壳层——只有 Rust、Win32 API 和你自己的 shell。这就是tmux on Windows能够既是原生、又是高性能的全部秘密。【免费下载链接】psmuxTmux on Windows Powershell - tmux for PowerShell, Windows Terminal, cmd.exe. Includes psmux, pmux, and tmux commands. This is native High-Performance Tmux designed for Windows in Rust 项目地址: https://gitcode.com/gh_mirrors/ps/psmux创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考