You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This change resolves an issue where the debugger would appear hung
until a key was pressed on Unix platforms.
This issue was caused by a quirk with the Unix implementation for
System.Console. The way cursor position is retreived is by writing
the cursor position escape sequence query and reading it from stdin.
To ensure those escape sequences don't trigger `Console.ReadKey`,
the internal stdin buffer is locked while `ReadKey` is running.
This means that while `ReadKey` is running, any attempts to query
cursor position will block the thread until the pending `ReadKey`
finishes.
The pipeline appears to hang on a debugger stop because there is
a pending `ReadKey` call in another thread and various methods in
both the internal PowerShell engine and in our host implementation
obtain the cursor position between command executions to determine
prompt location.
The best solution to this problem (credit goes to @rkeithhill) is to
create an alternative `ReadKey` implementation that waits for
`KeyAvailable` before blocking. However, if `ReadKey` is not currently
running then any input is echoed to the console. Aside from being
generally annoying, this presents a huge problem while trying to do
something like `Read-Host -AsSecureString`.
To get around this, I stripped out the native code from corefx
that disables console input echo, created a separate package that this
project can consume, and implemented a `WaitForKeyAvailable` method
that utilizes it.
This fix should be viewed as a temporary solution until either `ReadKey`
acts like this by default or a `ReadKeyAsync` method is implemented into
corefx.
0 commit comments