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

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

bug#26710: Fwd: 25.2; project-find-regexp makes emacs use 100% cpu


From: Dmitry Gutov
Subject: bug#26710: Fwd: 25.2; project-find-regexp makes emacs use 100% cpu
Date: Wed, 3 May 2017 03:14:52 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Thunderbird/53.0

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.





reply via email to

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