From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] master 1392ec7 2/3: A quicker check for quit
Date: Sun, 29 Jan 2017 19:30:47 +0200 [thread overview]
Message-ID: <83h94hydrs.fsf@gnu.org> (raw)
In-Reply-To: <fce04695-69d9-9dcb-5774-79879236f742@cs.ucla.edu> (message from Paul Eggert on Thu, 26 Jan 2017 09:45:09 -0800)
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 26 Jan 2017 09:45:09 -0800
>
> I was under the impression that if immediate_quit is true, then a tight
> loop in C doesn't need to call maybe_quit (the new name for QUIT), as
> C-g will error out immediately. There is longstanding code in the
> interpreter that assumes this, for example in the implementation of nth.
>
> Unfortunately my impression is incorrect. If you byte-compile this:
>
> (defun foo () (nth most-positive-fixnum '#1=(1 . #1#)))
>
> and load the resulting .elc file and then execute (foo) on a 64-bit
> Emacs displaying X, then C-g does not interrupt Emacs and Emacs hangs
> while counting up to 2**61. (C-g works as expected with emacs -nw.) I
> will look into fixing this longstanding bug, as well as fixing similar
> bugs that I recently introduced.
>
> This leads me to wonder: what's the point of immediate_quit? If
> immediate_quit doesn't always cause C-g to immediately quit, why are we
> bothering with an immediate_quit variable? Or if immediate_quit makes
> sense, then should we arrange for a C-g under X to behave more like C-g
> on a terminal, and do a longjmp? (Shudder.)
Once upon a time Emacs on X would read input from a SIGIO handler. If
you look in the sources for, say, Emacs 22.3, you will see there that
the function input_available_signal, which was installed as the SIGIO
handler, called handle_async_input, which read input from the
window-system. As part of reading input, Emacs would QUIT immediately
when it saw C-g, if immediate_quit was set and inhibit-quit was nil.
Thus, functions that wanted to be interruptible could set
immediate_quit non-zero and be sure they will be interrupted when the
user pressed C-g.
Later we decided that doing non-trivial stuff from signal handlers was
not such a good idea. So nowadays, the SIGIO handler just sets a flag
and returns. That flag is checked as part of QUIT (now rebranded as
maybe_quit), and if found set, we quit at that time.
This is why we started inserting QUIT in places that could potentially
hang or take a long time -- to allow the user to interrupt them sooner
rather than later. And that is why the recent changes which removed
QUIT and added setting immediate_quit non-zero are a move in the wrong
direction -- we should be doing the exact opposite.
> > Of course, for circular lists a better solution is to use the
> > hare&tortoise, e.g. with FOR_EACH_TAIL.
>
> Yes, that's something that could be done in these cases too. I'd like to
> get C-g fixed first, though.
If your plan for fixing this is anything other than restoring the
removed calls to maybe_quit, please show or describe your planned
changes before you install them. This tricky issue is further
complicated by the concurrency features, so I think we should make
sure the design is right before applying.
Thanks.
next prev parent reply other threads:[~2017-01-29 17:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170126052541.29089.5382@vcs.savannah.gnu.org>
[not found] ` <20170126052542.828422201BC@vcs.savannah.gnu.org>
2017-01-26 13:40 ` [Emacs-diffs] master 1392ec7 2/3: A quicker check for quit Stefan Monnier
2017-01-26 17:45 ` Paul Eggert
2017-01-26 20:02 ` Eli Zaretskii
2017-01-29 17:30 ` Eli Zaretskii [this message]
2017-01-29 17:47 ` Stefan Monnier
2017-01-29 20:16 ` Eli Zaretskii
2017-01-29 23:05 ` Paul Eggert
2017-01-30 15:33 ` Eli Zaretskii
2017-01-30 21:52 ` Paul Eggert
2017-01-31 15:48 ` Eli Zaretskii
2017-01-31 16:31 ` Stefan Monnier
2017-01-31 16:59 ` Paul Eggert
2017-02-02 0:01 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83h94hydrs.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).