[PATCH 0/4] Fix out-of-order keystrokes

[Takashi Yano]

Hi Johannes,

On Tue, 17 Mar 2026 14:57:05 +0100 (CET)
Johannes Schindelin wrote:
> Hi Takashi,
> 
> On Tue, 17 Mar 2026, Takashi Yano wrote:
> 
> > On Tue, 10 Mar 2026 17:56:52 +0900
> > Takashi Yano wrote:
> > > 
> > > On Fri, 6 Mar 2026 08:46:40 +0100 (CET)
> > > Johannes Schindelin wrote:
> > > > 
> > > > Hi Takashi,
> > > > 
> > > > On Tue, 3 Mar 2026, Takashi Yano wrote:
> > > > 
> > > > > On Mon, 02 Mar 2026 14:24:36 +0000
> > > > > "Johannes Schindelin wrote:
> > > > > > A Git for Windows user reported that typing in a Bash session while a native
> > > > > > Windows program is running (or has just exited) can produce scrambled input
> > > > > > -- e.g. typing "git log" yields "igt olg":
> > > > > > https://github.com/git-for-windows/git/issues/5632
> > > > > > 
> > > > > > [...]
> > > > > 
> > > > > Is the issue reproducible in pcon_activated case?
> > > > > Or disable_pcon case?
> > > > > 
> > > > > If you can reproduce the issue in cygwin, could you kindly please
> > > > > let me know how to reproduce it?
> > > > 
> > > > It is admittedly difficult to reproduce. It took me a good 4 days to get
> > > > to a reliable reproducer. And I failed to do this in manual mode, I had to
> > > > employ the help of AutoHotKey to do it. The result can be seen here:
> > > > https://github.com/dscho/msys2-runtime/blob/fix-jumbled-character-order/ui-tests/keystroke-order.ahk
> > > > 
> > > > Unfortunately, it is not quite stand-alone, it requires `powershell.exe`
> > > > in the `PATH`, and
> > > > https://github.com/dscho/msys2-runtime/blob/fix-jumbled-character-order/ui-tests/ui-test-library.ahk
> > > > and
> > > > https://github.com/dscho/msys2-runtime/blob/fix-jumbled-character-order/ui-tests/cpu-stress.ps1
> > > > in the same directory. I just verified that it reproduces even with vanilla
> > > > Cygwin, using the latest AutoHotKey version from
> > > > https://github.com/AutoHotkey/AutoHotkey/releases/tag/v2.0.21. I ensured
> > > > that Cygwin's `bin` directory is first in the `PATH` and then ran, from a
> > > > PowerShell session:
> > > > 
> > > >   & "<path-to>\AutoHotkey64.exe" /force keystroke-order.ahk "$PWD\log.txt"
> > > > 
> > > > What this test does: It runs a small PowerShell script designed to add a
> > > > bit of CPU load and then spawns a Cygwin process (`sleep 1`). While these
> > > > are running, it then types _very_ rapidly four characters, then two
> > > > backspaces, then repeats that quite a few times ("ABXY" then deleting
> > > > "XY", then "CDXY", deleting "XY", etc). The number of characters was
> > > > chosen high enough that this reproducer basically reproduces the issue on
> > > > the first try. The "log.txt" file contains a detailed log including the
> > > > verdict. In my latest test, for example, it shows:
> > > > 
> > > >   Iteration 1 of 20
> > > >   MISMATCH in iteration 1!
> > > >   Expected: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789
> > > >   Got:      ABCDEFGHIJKLMNOPQRXSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789
> > > > 
> > > > You will spot the "X" between "R" and "S", meaning that the backspace was
> > > > not able to remove the "X" because it was routed to the wrong pipe, or
> > > > after the "X" was already consumed.
> > > 
> > > Thanks for the reproducer. I finally could reproduce the issue!
> > > Please let me take a look.
> > 
> > I finally have a patch series that fixes all the issue triggered by
> > this reproducer.
> 
> Seeing as you did not reuse any part of my patches, not even the carefully
> crafted commit messages, I wonder why you find them so horrible that you
> don't even review them, let alone consider using them.
> 
> > I'll submit the patch series to cygwin-patches mailing list.
> > Could you please test?
> 
> Yes, I tested. There is already a problem in the `cmd.exe` test I
> introduced in response to your feedback. What it does is to launch
> `cmd.exe`, wait a few milliseconds, and then start typing `echo
> <long-string>`.
> 
> As you can see from the output here, that does not work. The first two
> characters never make it to `cmd.exe`, and besides, `cmd.exe` is then
> stuck:
> 
> -- snip --
> $ cmd.exe
> eMicrosoft Windows [Version 10.0.26200.7984]c
> (c) Microsoft Corporation. All rights reserved.
> 
> D:\git-sdk-64\usr\src\MSYS2-packages\msys2-runtime\src\wip\ui-tests\msys2>ho ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789
> -- snap --

This seems to be a deadlock caused by PATCH 6/6.

I've revised the PATCH 6/6 v2 so that to_be_read_from_nat_pipe() returns
false if pcon_start is asserted while trying to acuqire pipe_sw_mutex.
This is because if the slave is in setup_pseudoconsole(), the slave has
pipe_sw_mutex acquired and asserts pcon_start. In pcon_start state,
other input than response to CSI6n should go to cyg-pipe.

> In my investigations (supported by Claude Opus, because I still have a
> hard time with the current shape of the code and its lack of documenting
> ideas clearly), I stumbled across something that I _think_ is the actual
> cause of the many problems: When a native program is started, there is
> this time window during which the console owner is the current process (in
> my case, Bash), _not_ the native process (because it does not exist yet or
> the parent process does not yet know its process ID). When any kind of
> transfer happens during that time (and it does!), we're heading straight
> into trouble. I get the impression that we need to address this, to close
> that time window, not by narrowing it further, but by eliminating it
> entirely: while a native process is starting up that will become the
> console's owner, no transfer should happen.
> 
> Now, I really would like to collaborate with you on that. But I have to
> admit that I'm struggling a bit when you don't even comment on the
> contents of the commit message or patch to help me improve them, or when
> you just ignore those patches and instead write completely different ones.
> 
> Can we work on this together, please?

With pleasure!

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>