bug#69083: Emacs's keyboard hook state is not reset on session lock (Windows)

[Eli Zaretskii <eliz@gnu.org>]

> From: Raffael Stocker <r.stocker@mnet-mail.de>
> Cc: 69083@debbugs.gnu.org
> Date: Mon, 04 Mar 2024 19:10:33 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The order is not important, I just didn't know where to look to get
> >> a frame; sorry for the noise.  I now use ‘Fnext_frame’.
> >
> > Unfortunately, I don't think you cannot use Fnext_frame here.  The
> > function which calls it, w32_wnd_proc, runs in a separate thread, so
> > it generally cannot access Lisp objects safely.  However, it is okay
> > to traverse the list of the frames, as w32_window_to_frame does, see
> > the comment at the beginning of w32_wnd_proc.  So I think you could
> > use a similar loop with FOR_EACH_FRAME, and use some frame from there,
> > perhaps the first one?
> >
> > Alternatively, and maybe more safely, you could call
> > maybe_pass_notification from w32_destroy_window, which is called from
> > the main (a.k.a. "Lisp") thread, so then you can use Fnext_frame
> > (actually, I would make next_frame extern instead of static and call
> > it directly).  This means the notifications are passed a bit before
> > the frame is actually deleted by the OS, but I think this is okay?
> 
> I went with the first option, using FOR_EACH_FRAME, because I am not
> sure about the safety of modifying the kbdhook struct from the other
> thread.

Thanks.  I needed to fix this in small ways, to get it to compile with
mingw.org's MinGW, and I've now installed the results on the master
branch.

With that, I'm closing this bug.