GNU bug report logs - #73046
29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Suhail Singh <suhailsingh247 <at> gmail.com>
Cc: michael.albinus <at> gmx.de, suhailsingh247 <at> gmail.com, 73046 <at> debbugs.gnu.org
Subject: Re: bug#73046: 29.4; Emacs 100% CPU usage for several seconds when
 opening dired buffer over TRAMP
Date: Wed, 11 Sep 2024 14:50:14 +0300

> From: Suhail Singh <suhailsingh247 <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  suhailsingh247 <at> gmail.com,
>   73046 <at> debbugs.gnu.org
> Date: Tue, 10 Sep 2024 21:05:29 -0400
> 
> Michael Albinus <michael.albinus <at> 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.

Previous Next

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