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

[Eli Zaretskii <eliz@gnu.org>]

> From: Suhail Singh <suhailsingh247@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  suhailsingh247@gmail.com,
>   73046@debbugs.gnu.org
> Date: Tue, 10 Sep 2024 21:05:29 -0400
> 
> 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 think Michael just did (see below).

> 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?

When we call sit-for, we yield the CPU for whatever other jobs are
waiting, so we don't hog the processor.

> 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.

How would that help?  Tramp must still wait for the response to
proceed with what it does.

> 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)?

Every Lisp program runs in a single thread, so how can that be done in
parallel?

> 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)?

Emacs doesn't support parallel processing, because introducing this
into the original single-threaded design is very hard at best, due to
a huge global state.  We have Lisp threads, but only one thread can
run at any given time.

> > 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.

Thanks.