GNU bug report logs - #32502
27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gemini Lasswell <gazally <at> runbox.com>
Cc: 32502 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
Subject: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs
Date: Fri, 31 Aug 2018 09:52:19 +0300

> From: Gemini Lasswell <gazally <at> runbox.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  32502 <at> debbugs.gnu.org
> Date: Thu, 30 Aug 2018 12:29:44 -0700
> 
> I don't understand why this is so complicated.  Why not just have the
> thread show a message, instead of having it send a signal which gets
> translated into an event that makes the main thread show a message?

Because the echo area could be showing something important from the
main (or some other) thread, e.g. if the user typed "C-x C-f", but
didn't yet finish responding to the request for the file name.
Displaying something from another thread will wipe out that
interaction's text.

By submitting an event to the main thread, we make sure these two
interactions will be serialized.

> Also, if we eventually implement one of the proposals in emacs-devel to
> allow threads other than the main one to accept keyboard input, then
> there would be no guarantee that putting the event in the keyboard
> buffer would get it to the main thread.

I don't think it matters, because it will get to the thread which is
reading input events, and that thread will then act on the event.  But
if it turns out it does matter, we can always tag each even with its
target thread or something, and modify the queue handling to only act
on events whose target is the current thread.

Previous Next

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