GNU bug report logs - #26710
project-find-regexp blocks the UI

Previous Next

Full log

Message #46 received at 26710 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: hariharanrangasamy <at> gmail.com, 26710 <at> debbugs.gnu.org
Subject: Re: bug#26710: Fwd: 25.2; project-find-regexp makes emacs use 100% cpu
Date: Wed, 3 May 2017 03:14:52 +0300

On 02.05.2017 20:26, Eli Zaretskii wrote:

> The sentinel/filter won't be called at all if keyboard/mouse input is
> available.  Once they are called, if each call takes a long processing
> time, the UI could feel sluggish, yes.

Hmm, and if we're in "many calls, each of them fairly fast" situation?

Sounds like the UI might be quite usable (but doing anything with it 
would slow down the processing of search results).

> But I don't quite see how
> using threads will avoid the same problem, since the mechanism for
> thread switch is basically the same as for multiplexing UI with
> subprocess output.

Right, threads would server only to make the code more readable. With 
filters, we'll have callbacks.

Threads can make this code look sequential, like iterating over a sequence.

> IMO, we should first explore the async subprocess road.

OK.

>> We'll probably be saved by filters having to wait until the current
>> command finishes executing, though.
> 
> Not sure I follow you: a filter function is called whenever some
> output arrives from the subprocess.  So they don't need to wait for
> the subprocess to finish.

The current command, as in "Emacs command loop" command. Anyway, you've 
addressed this issue in the next email.

Previous Next

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