GNU bug report logs - #65837
30.0.50; Debugger in non-main threads

Previous Next

Full log

Message #20 received at 65837 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 65837 <at> debbugs.gnu.org
Subject: Re: bug#65837: 30.0.50; Debugger in non-main threads
Date: Sat, 09 Sep 2023 19:46:22 +0300

> From: Helmut Eller <eller.helmut <at> gmail.com>
> Cc: 65837 <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.