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

[Michael Albinus <michael.albinus@gmx.de>]

Dima Kogan <dima@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.