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

From: Michael Albinus <[email-masked]>
Date: Sun, 25 Jul 2021 14:37:55 +0200

Dima Kogan <[email-masked]> 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.