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

Previous Next

Full log

View this message in rfc822 format

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

Eli Zaretskii <eliz <at> gnu.org> writes:

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

I was imagining a version of TRAMP that was asynchronous.  I understand
now that it isn't.

-- 
Suhail

Previous Next

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