bug#68914: Windows makes Emacs choke on and swallow the WIN keys

[Eli Zaretskii <eliz@gnu.org>]

> From: Raffael Stocker <r.stocker@mnet-mail.de>
> Cc: 68914@debbugs.gnu.org
> Date: Sun, 04 Feb 2024 14:02:02 +0100
> 
> > It would be better to have some independent verification that this is
> > what happens.  Is there any way to find out whether the hook was
> > removed, even from outside of Emacs?
> 
> MS say there is no direct way.  But for debugging it might be possible
> to produce some output whenever the hook is called, if that is missing,
> we would know.

That could be a good solution, yes.

> > I find it hard to believe that
> > we could miss the 200-ms deadline on modern systems.  Are your systems
> > heavily loaded at times?  What kind of CPU do you have on those
> > systems?  Emacs can hog CPU with only a single thread, so if your
> > systems have a reasonably modern CPU, Windows should have plenty of
> > execution units to spread any additional load without preempting
> > Emacs.
> 
> It (also) happens when the systems are basically idle, with only some
> keyboard input.  The systems are also relatively new (Intel i7 or i5
> from a few years ago).

That's even weirder.

> > Another idea is to add code to Emacs that measures the time it takes
> > Emacs to produce the WM_KEYUP event, and log some message if that
> > takes more than some threshold.
> 
> I have managed to set up a build environment on one of the machines and
> I will try to experiment with this in the coming weeks. Perhaps I can
> find out more.

Thanks.

> >> - If Emacs being too slow somewhere is indeed the problem, can it be
> >>   sped up, maybe by putting the slow stuff in a different thread than
> >>   the low level keyboard handling?
> >
> > According to the MS documentation, the hook is called by sending a
> > message to the thread that installed the hook, which in our case is
> > already a separate thread, not the main Lisp thread (which is likely
> > to be busy at times).  The thread which handles the hook callbacks is
> > the input thread, which is relatively light-weight and shouldn't be
> > too busy.
> 
> We saw the correlation with working on a network share and IIUC Windows
> Defender blocks a process/thread while writing (or only closing?) a
> file.  Therefore my suspicion.  But if saving files is not done in the
> same thread as input, that can't be it...

Our input thread doesn't write to any files, not in our code anyway.
It just runs the message pump and little else.

> >> - Can we put the workaround described above (with the LowLevelHooksTimeout
> >>   value) into the Emacs documentation so it is findable?
> >
> > Please suggest the text to put in the manual to document this.
> 
> I attached a patch that adds a paragraph to the “Windows Keyboard” section.

On second thought, I think this kind of problems are better described
in etc/PROBLEMS, so I have now added something there with the
description of the problem and the workaround/