Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,7 @@ windows-sys = { version = "0.61.2", features = [
] }

[target.'cfg(windows)'.dev-dependencies]
windows-sys = { version = "0.61.2", features = ["Win32_System_Console"] }
windows-sys = { version = "0.61.2", features = ["Win32_System_Console", "Win32_System_Threading"] }

[profile.release]
codegen-units = 1
Expand Down
17 changes: 17 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -269,6 +269,23 @@ multiple connections, namespace ownership, cancellation, and final-frame
completion. These checks do not yet establish Windows daemon support or
complete ConPTY shutdown behavior.

On Windows, normal root-child exit hands the ConPTY master to the existing
child-wait worker for closing. The actor and reader continue draining until the
real output-pipe EOF; only then is the final exit event published. The worker
checks the root's wait handle at 10 ms intervals. After the master is handed
off, Windows input and resize requests fail with a child-exited error; final
snapshots, rows, and replay remain readable until the terminal is removed.
Unix post-exit PTY operations retain their existing behavior.

### Known Linux cleanup limitation

A child that exits without consuming a large queued PTY write can leave the
Linux master write blocked after the child, actor, reader, and waiter have
already stopped. `TerminalService::terminate` or service drop can then wait
indefinitely for the writer thread. This pre-existing Unix I/O limitation is
not repaired by the Windows cleanup work. A test watchdog or the daemon's
forced-exit deadline does not prove that those worker threads were joined.

Once the workflow is on `master`, it can also be run manually against a branch:

```sh
Expand Down
Loading
Loading