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 #26 received at 49714 <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: Michael Albinus <michael.albinus <at> gmx.de>
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: Sat, 24 Jul 2021 11:52:32 -0700

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

> Dima Kogan <dima <at> 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!

Previous Next

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