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

[Dima Kogan]

Michael Albinus <michael.albinus@gmx.de> writes:

> Dima Kogan <dima@secretsauce.net> writes:
>
>>>> There should be a loop, but emacs shouldn't be using all my CPU cycles
>>>> while waiting for user interaction. Emacs can select() on the ssh
>>>> process file descriptor, and sleep until the ssh process has stuff to
>>>> say.
>>>
>>> Well, I'm on Lisp level. I just have accept-process-output, and in my
>>> loop I check whether there is new output. There's no low level API to
>>> let Emacs sleep for the ssh process file descriptor.
>>
>> It just sounds unbelievable that emacs can't do blocking reads from the
>> lisp level. Let me look at (accept-process-output)
>
> accept-process-output could block. But it blocks the whole Emacs then,
> which isn't what we want.

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

Thanks!