GNU bug report logs - #64819
30.0.50; condition-wait not interruptible

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 64819 <at> debbugs.gnu.org
Subject: Re: bug#64819: 30.0.50; condition-wait not interruptible
Date: Mon, 24 Jul 2023 16:34:17 +0300

> From: Helmut Eller <eller.helmut <at> gmail.com>
> Cc: 64819 <at> debbugs.gnu.org
> Date: Mon, 24 Jul 2023 14:58:37 +0200
> 
> On Mon, Jul 24 2023, Eli Zaretskii wrote:
> 
> > How will we know what to do with C-g if some thread runs Lisp, while
> > one or more other threads are stuck in condition-wait? wouldn't you
> > expect in this case to have C-g go to the running thread?
> 
> We could say that C-g sets quit-flag and causes all blocking calls to
> condition-wait to return nil (spurious wakeup).  At that point all
> threads are conceptually running.  Then the first thread (unspecified
> which one) who calls maybe_quit() finishes handling C-g and clears
> quit-flag afterwards.  Those threads who don't feel prepared to handle
> C-g can bind inhibit-quit.

I don't think we can allow more than one thread at a time to run the
parts of the Lisp interpreter that lead to maybe_quit.

Also, I don't think what you describe, even if it were possible, is
what users expect: they expect that the thread which is running is
interrupted, and either exits or handles the quit, and all the other
threads still wait for the condition var.

So I think to do anything smarter in the deadlock situation you
describe we'd need to detect the deadlock first.  Once we do that
(which isn't easy: perhaps do that in the signal handler?), we'd need
to decide which of the deadlocked threads to free, which is also not
trivial.  Hmmm...

Btw, did you try your recipe in a Unix TTY?  There, C-g actually
delivers SIGINT to Emacs, so you might see a different behavior (or a
crash ;-).

Previous Next

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