bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP

[Suhail Singh <suhailsingh247@gmail.com>]

Michael Albinus <michael.albinus@gmx.de> writes:

> Tramp used a non-zero timeout in the past. This was removed some years
> ago, I don't remember the reason.

The timeout in tramp-accept-process-output was disabled in commit
54ef338ba3670415cf47fabc33a92d4904707c7e .  The commit mentions
bug#61350 , however, it's not clear (based on briefly skimming the
discussion there) that this change was ever necessary.  If not, should
the timeout be reintroduced?

> I've added (sit-for 0.005) in the loop calling
> tramp-accept-process-output. It decreases the CPU load from 100% to
> something between 45..50%, when waiting for a response from remote.

I am trying to better understand what's going on, so the following is
simply for my understanding.  Use your discretion when responding.

IIUC, we're still actively waiting for the output from the remote host,
but simple not _exclusively_ doing so thanks to the `sit-for'.  Is my
understanding correct?  If so, isn't there some mechanism to specify a
continuation that's run once the TRAMP process produces output?  Such a
mechanism shouldn't require a `sit-for' to yield control.

In other words, isn't it possible to do both font-locking and getting
the response over ssh concurrently (of the main thread, as well wrt each
other)?  If not, are there technical challenges in doing so, or simply
that it's not been implemented (and thus, possibly, we may not know what
the challenges are)?

> Pushed to master

Thank you.  I can test this (applied onto 29.4) later in the week along
with the `dired-font-lock-keywords' patch and report back.

-- 
Suhail