fix(windows): non-blocking input loop, restore Ctrl+C, drive-root path walk#74
Open
FXschwartz wants to merge 5 commits into
Open
fix(windows): non-blocking input loop, restore Ctrl+C, drive-root path walk#74FXschwartz wants to merge 5 commits into
FXschwartz wants to merge 5 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Improves path discovery behavior and Windows console input handling by making project root detection terminate safely across platforms and keeping the Windows stdin event loop responsive (including Ctrl+C/SIGINT behavior).
Changes:
- Added unit tests for
getProjectDirectory()behavior with/withoutpubspec.yaml. - Updated
getProjectDirectory()to terminate by comparing paths (works for Windows drive roots) and return cwd when no ancestor containspubspec.yaml. - Updated Windows stdin backend to re-enable
ENABLE_PROCESSED_INPUTand poll input availability withWaitForSingleObjectto avoid starving the Dart event loop.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| test/utils/nocterm_paths_test.dart | Adds tests validating getProjectDirectory() ancestor walking behavior. |
| lib/src/utils/nocterm_paths.dart | Fixes termination condition when walking to filesystem roots; changes fallback behavior. |
| lib/src/backend/win32_ansi_stdin.dart | Makes Windows stdin loop responsive + preserves Ctrl+C generation by adjusting console mode and using a bounded wait. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // starving timers and signal handlers. | ||
| final waitResult = _waitForSingleObject(_inputHandle, _pollIntervalMs); | ||
| if (!_running) break; | ||
| if (waitResult != _waitObject0) continue; |
This was referenced May 21, 2026
Author
|
@Norbert515 Sorry for the ping, I'm sure you are busy but when you get a chance could you take a look at this PR? No rush! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes three Windows only issues:
1.
Win32AnsiStdin._eventLoopblocks the Dart isolateReadConsoleInputWwas called with no timeout, blocking the OS thread until input arrived. While blocked, no timers, futures, signal handlers, or render frames fire. Theawait Future.delayed(Duration.zero)at the top of the loop only yields between blocking calls.Fix: call
WaitForSingleObject(handle, 16)first; only callReadConsoleInputWwhen the handle is signaled. Caps FFI time at ~16ms.2. Ctrl+C path inactive on Windows
enableRawModecallsstdin.lineMode = false, which on Windows clearsENABLE_PROCESSED_INPUT. Without that flag, Windows doesn't generateCTRL_C_EVENT, so Dart'sProcessSignal.sigint.watch()doesn't fire.Fix: re-assert
ENABLE_PROCESSED_INPUTinstartEventLoop(). WithENABLE_LINE_INPUTstill off, only Ctrl+C is intercepted; other Ctrl+letter combos still arrive as key events.3.
getProjectDirectory()doesn't terminate on Windows drive rootsif (newParent == parent)is identity equality onDirectory(.parentreturns a new instance each call, so this never matches).if (newParent.path == '/')is POSIX-only. From a directory with nopubspec.yamlancestor on Windows, the walk iterates onC:\indefinitely. Called synchronously fromLogServer._writePortFile(), which is awaited in_runAppbeforeTerminalBinding.initialize(), sorunAppitself doesn't progress.Fix: compare paths (
newParent.path == parent.path), and fall back toDirectory.current.pathinstead of throwing.I also added new unit tests in
test/utils/nocterm_paths_test.dartcovergetProjectDirectory's three behaviors