From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dima Kogan Newsgroups: gmane.emacs.bugs Subject: 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 Message-ID: <87r1fnr1cf.fsf@secretsauce.net> References: <87o8asu1mg.fsf@jpl.nasa.gov> <87sg03apj1.fsf@gmx.de> <87zgubr31n.fsf@secretsauce.net> <87pmv7o9hn.fsf@gmx.de> <87wnpfr25i.fsf@secretsauce.net> <87czr7o8lc.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9860"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.15; emacs 28.0.50 Cc: 49714@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 24 20:54:54 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m7MnV-0002Mt-Pk for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 24 Jul 2021 20:54:53 +0200 Original-Received: from localhost ([::1]:59814 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m7MnU-00064v-S6 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 24 Jul 2021 14:54:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46190) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m7Mlj-0004V4-Fw for bug-gnu-emacs@gnu.org; Sat, 24 Jul 2021 14:53:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35478) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m7Mli-0004Rc-EE for bug-gnu-emacs@gnu.org; Sat, 24 Jul 2021 14:53:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m7Mli-0003UR-4k for bug-gnu-emacs@gnu.org; Sat, 24 Jul 2021 14:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dima Kogan Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 24 Jul 2021 18:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49714 X-GNU-PR-Package: emacs Original-Received: via spool by 49714-submit@debbugs.gnu.org id=B49714.162715276313377 (code B ref 49714); Sat, 24 Jul 2021 18:53:02 +0000 Original-Received: (at 49714) by debbugs.gnu.org; 24 Jul 2021 18:52:43 +0000 Original-Received: from localhost ([127.0.0.1]:47024 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m7MlO-0003Th-TZ for submit@debbugs.gnu.org; Sat, 24 Jul 2021 14:52:43 -0400 Original-Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:39277) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m7MlM-0003TQ-Ms for 49714@debbugs.gnu.org; Sat, 24 Jul 2021 14:52:41 -0400 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id D622D32008FE; Sat, 24 Jul 2021 14:52:34 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sat, 24 Jul 2021 14:52:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secretsauce.net; h=references:from:to:cc:subject:in-reply-to:date:message-id :mime-version:content-type; s=fm3; bh=su75uClqmSlwxIc6VGp52/tF9A AO6pzqahnWLRjlDRg=; b=l8rpxAadSxt/S3wFbvZy1BdBgkVOSOc17WhDNOWH2F uFlPuQDJH7zi8Q43tl9j9QSRkUKshY08PLA697ERxUs16MltvRgfVeBasWU5MumT AsCYO8FkuZgYLixuc4sn4TcZvYfA8A0cy3kQNI6c+BpfXhyjcflMC4+mue6r0aJ/ R2AlXSihINSCj+w1VD2edyNzzNdIdLJmKF3VzWpwSX5wZfxn9VsTs45tDSGu2MUH rX2uQdRQtHt79o/y9032Rxk+/ipSpqDscJOCGcrqRxKT4TNuoL1uZFLYrNjXqd9Q 3EXD4VkKUW+8NR6xWVT2zcypIPosX5mRP+KK8bB9errQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=su75uC lqmSlwxIc6VGp52/tF9AAO6pzqahnWLRjlDRg=; b=NfGruLu5d+gcFtnhIN+llv +av0NlXt1D3AqrHpBeJU6SDh4mZiBYMpi7hVBOU6PuoHpaBswSVPUYVtAKLVHzyX rIfeo0NfqC6lY6cZRvl6cTnZYmBpoGvYx6WEPVlyX6aWdZmuwJuK2/8XpmjHCQKL RO4h0CIEa6mjKAyfCOrWbev7SePbz8PWKh0ZOX8RqQu42+OCeJBBo7lNQPRjFd1C DSUpDNrh+Wx3srsyt0IcTdlyYBS4VFobOnvzcgUuAeGb2Jx3iUGzS9t8+1RL3Yuj 3Up4pewnq9l81UYlgphEcr+wLKg5CF1t/9+6Ld5eCeQby7yjqFbAH+C+G5fHkwwA == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrgedtgdduvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfhgfhffvufgjfffkgggtsehttdertddtredtnecuhfhrohhmpeffihhmrgcu mfhoghgrnhcuoeguihhmrgesshgvtghrvghtshgruhgtvgdrnhgvtheqnecuggftrfgrth htvghrnhepfeevfefgtedtfedvtefgkedvtdffvefhveellefhjeehlefgudfftdeiudeu keehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug himhgrsehsvggtrhgvthhsrghutggvrdhnvght X-ME-Proxy: Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 24 Jul 2021 14:52:33 -0400 (EDT) In-reply-to: <87czr7o8lc.fsf@gmx.de> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:210661 Archived-At: Michael Albinus writes: > Dima Kogan 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!