bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#32487: 26.1.50; keyboard-quit while main thread blocked crashes Emac


From: Gemini Lasswell
Subject: bug#32487: 26.1.50; keyboard-quit while main thread blocked crashes Emacs
Date: Wed, 22 Aug 2018 07:39:35 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux)

Eli Zaretskii <address@hidden> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]