bug#53871: 29.0.50; Emacs freezes with new child-frame option

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Tue, 08 Feb 2022 11:35:17 +0100
> Cc: 53871@debbugs.gnu.org
> 
> > 1) emacs -Q
> > 2) eval (setq show-paren-context-when-offscreen t) in scratch
> > 3) M-x find-library RET paren RET
> > 4) M-g c 13902 RET
> > 5) With the mouse cursor, grab the scroll bar and move down so far to
> >    get the context
> >    'Matches (defun show-paren--show-context-in-child-frame (text)'
> >    in the echo area.
> > 6) eval (setq show-paren-context-when-offscreen 'child-frame) in scratch
> > 7) Repeat 5) and Emacs freezes
> >
> > This is with repo-version 90eb6a7fe4 on Win10.
> 
> I can't reproduce with the slightly later version 9d1ae05442 on
> GNU/Linux with a pgtk build.  When scroll up and down (only so far as to
> keep point at the closing paren of the defun), I'll see the child frame
> displaying the "(defun ...)" line whenever I stop scrolling for a
> second.
> 
> After doing that for I while, I checked that `(frame-list)` still
> contains just a single frame.  How is that for you?  Do you have many
> frames in there?  And do you recover from the freeze?

The number of the frames is not the problem.  Yes, there's just one
frame on Windows as well.  And no, there's no way to recover, because
the implementation of this feature seems to cause on MS-Windows a
deadlock between two threads, one of which is the main thread.

On Windows, creating a frame involves sending a message to a separate
UI thread and waiting for that thread to respond, but in this
scenario, doing that seems to lead to some kind of deadlock, whereby
both threads wait for messages.

Martin, any ideas?  I can show the backtrace from the freeze, if that
helps.