[Top][All Lists]

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

Re: [Emacs-diffs] master 1392ec7 2/3: A quicker check for quit

From: Paul Eggert
Subject: Re: [Emacs-diffs] master 1392ec7 2/3: A quicker check for quit
Date: Tue, 31 Jan 2017 08:59:54 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0

On 01/31/2017 07:48 AM, Eli Zaretskii wrote:
Then maybe we should add maybe_quit calls in regex.c instead?

We already have them there, everywhere that the regex code could do a lot of computation. In places where it's fast and bounded, we don't have them as they would slow things down.

Currently, immediate_quit is non-zero all the time re_search_2 runs,
so on a TTY a C-g will can stop regex.c in its tracks anywhere.  I
thought we wanted to make GUI sessions as responsive as TTY sessions.

That has not been my goal. C-g in GUI sessions is already plenty fast enough for human interaction. (If they are not, we should fix that; but I don't know of any bugs in the regexp-searching area.) Whatever way we do it, treating GUI and TTY sessions the same as far as quitting goes simplifies maintenance significantly.

It should be OK. The current master sets immediate_quit=true in back_comment's 
callers (both scan_lists and Fforward_comment), so current master already lets 
back_comment quit.
Yes, but that is why we have gl_state-related dance in
handle_interrupt, and your changes delete that part.

That gl_state-related dance is present only because 'quit ()' can return instead of quitting, which means that the code could asynchronously reenter the regexp code. Since that call to 'quit' is no longer present, that sort of reentry is no longer possible, and we don't need the dance.

If Emacs quits in back_comment, it should longjmp to code that reinitializes 
gl_state before using it.
But unwinding the Lisp stack could run some Lisp that uses syntax.c
functions, before we longjmp, right?

No, because the interruptible regexp code does not call Lisp code: it does not try to reenter itself.

That assumes all the immediate_quit=true settings were safe.

That sort of thing has been in Emacs for ages, and I daresay it's been tested at least as well as, if not even more than, the GUI approach to quitting searching. When I was using Emacs in the 1980s computers were not nearly as fast and people's keystrokes were just as fast as they are now. So it's reasonable to place some confidence in those settings. Quite possibly we could make improvements in this area later, but it's conservative to stick with those settings for now.

Speed is not a problem, as C-g (with the proposed changes) should quit just as 
fast on a TTY as it already does under X, and it's been working that way under 
X for some time.
No, it will be slower.

Apparently I was not clear enough. I was not saying that the change won't delay C-g handling in ttys; obviously it will. All I was saying is that C-g will be handled as fast on ttys as it is on GUIs, which is good enough.

The new patches still include both rarely_quit and incr_rarely_quit
(in the second patchset), which I thought you decided to remove.  Did
you send the correct patches?
Yes, the third patch removed incr_rarely_quit. I'm not a big fan of rewriting history. For your convenience I've attached a combined patch, that's just all the patches squashed together so that there isn't any incr_rarely_quit.

Attachment: quit.diff
Description: Text Data

reply via email to

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