bug#65837: 30.0.50; Debugger in non-main threads

[Eli Zaretskii <eliz@gnu.org>]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: 65837@debbugs.gnu.org
> Date: Sat, 09 Sep 2023 18:23:29 +0200
> 
> On Sat, Sep 09 2023, Eli Zaretskii wrote:
> 
> >> Is there a design/plan for how recursive-edit is supposed to work in
> >> non-main threads?
> >
> > Not that I know of, no.  But you seem to be asking mainly about
> > reading events, not about recursive-edit?
> 
> Well, the debugger calls recursive-edit and if it's not clear what
> recursive-edit is supposed to do, then replacing recursive-edit with
> something more reliable would be my first step to improving the
> debugger.

If recursive-edit is run by the same thread which was running before
the debugger was entered, and the debugger never calls one of the
primitives that enter the idle loop (sit-for etc.), then I don't think
problems will happen, because it basically means the thread which
entered the debugger keeps running.  But if the debugger causes its
thread to yield, some other thread could grab the global lock, and
then all hell will break loose.

So I think the only reasonably practical way to make this particular
use case stable is to disable thread switching for as long as the
debugger is active.  WDYT?