GNU bug report logs - #49714
28.0.50; TRAMP burns CPU and has insufficient user reporting when using xxxx-sk SSH keys

Previous Next

Full log

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 49714 <at> debbugs.gnu.org
Subject: Re: bug#49714: 28.0.50; TRAMP burns CPU and has insufficient user
 reporting when using xxxx-sk SSH keys
Date: Sun, 25 Jul 2021 14:37:55 +0200

Dima Kogan <dima <at> secretsauce.net> writes:

Hi Dima,

> But emacs is blocked anyway. At least with the code as it is today,
> while TRAMP is spinning the cpu waiting for ssh to respond, emacs is not
> responsive to any user input. In a perfect world we'd block on the read,
> and then go back to the emacs main loop to do other stuff, but that's
> hard for all the reasons you know.

That requires a Tramp with thread support. I worked on this years ago,
but this is stalled.

> If we don't go back to the main loop
> (as we don't today), then we don't lose anything by a blocking read. You
> know much more about the internals than me; is there other work
> happening between the checks during our non-blocking read?

Other processes could provide their output, process filters, process
sentinels, timers could run, all these asynchronous tasks Emacs runs in
the background.

> Thanks!

Best regards, Michael.

Previous Next

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