GNU bug report logs - #32487
26.1.50; keyboard-quit while main thread blocked crashes Emacs

Previous Next

Full log

View this message in rfc822 format

From: Gemini Lasswell <gazally <at> runbox.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 32487 <at> debbugs.gnu.org
Subject: bug#32487: 26.1.50; keyboard-quit while main thread blocked crashes Emacs
Date: Wed, 22 Aug 2018 07:39:35 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

> That's ample punishment for a buggy program, don't you think?

I thought so too at first, when I first came across this.  But the
reality is that new bugs get added to Emacs all the time, despite our
best efforts, and the fact that C-g can't interrupt the thread
primitives raises the risk of new bugs being severe bugs.

If a user encounters a hanging bug in non-threaded Lisp, it's very
likely that she can recover from it with C-g, and continue using Emacs.
But if the user encounters a hanging bug in threaded Lisp, she will lose
her Emacs session.

Emacs is also a development environment, and it's a much less friendly
place to develop programs when it's easy for buggy programs to crash the
development environment.  Obviously it's not hard to write Lisp that
makes Emacs unresponsive or unusable, if you're trying to do that.  But
in the act of trying to write useful Lisp, it's been rare in my
experience.  With the thread primitives it's much easier to do
unintentionally.

Most of the time when I write buggy Lisp that stops responding, I can
find out what the problem is by stopping it with C-g, using
toggle-debug-on-quit, restarting my problematic code, C-g again.  This
doesn't work if the main thread is stuck in a thread primitive.

Previous Next

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