From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#56342: TRAMP (sh) issues way too many commands, thus being very slow over high-ping networks Date: Mon, 04 Jul 2022 13:19:45 +0200 Message-ID: <87sfnhazvy.fsf@gmx.de> References: <8735fjh5ge.fsf@gmx.de> <87v8sefl2f.fsf@gmx.de> <874jzyc9u9.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="39310"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 56342@debbugs.gnu.org To: Paul Pogonyshev Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 04 13:29:55 2022 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 1o8KH4-000A57-90 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 04 Jul 2022 13:29:54 +0200 Original-Received: from localhost ([::1]:43854 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o8KH2-00031R-T5 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 04 Jul 2022 07:29:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37972) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o8K7W-0006Is-W4 for bug-gnu-emacs@gnu.org; Mon, 04 Jul 2022 07:20:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52412) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o8K7W-0006FK-MH for bug-gnu-emacs@gnu.org; Mon, 04 Jul 2022 07:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o8K7W-0006RE-HQ for bug-gnu-emacs@gnu.org; Mon, 04 Jul 2022 07:20:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Jul 2022 11:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56342 X-GNU-PR-Package: emacs Original-Received: via spool by 56342-submit@debbugs.gnu.org id=B56342.165693359424722 (code B ref 56342); Mon, 04 Jul 2022 11:20:02 +0000 Original-Received: (at 56342) by debbugs.gnu.org; 4 Jul 2022 11:19:54 +0000 Original-Received: from localhost ([127.0.0.1]:46308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o8K7O-0006Qg-BP for submit@debbugs.gnu.org; Mon, 04 Jul 2022 07:19:54 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:54269) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o8K7N-0006QS-14 for 56342@debbugs.gnu.org; Mon, 04 Jul 2022 07:19:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1656933586; bh=h8vZtzxJxknb48sioZgkMRt+/8FaBbm7di2v8kCQUYQ=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=CRSaYIjC/RAMxWLztBvzs1bLh23U2SSBW0ap5a+6q3uMvPq0ci54UqSD9zHnOVheJ WwMQVLBuamaap+/O1OHUeT2Ej4co0qIcMa3LADZywzIvENBEb8svokkdnxwnlHRZIF uxxHz+4/VSojPyaf7Iwgui/5szWL37irlrzPD0a8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from gandalf.gmx.de ([79.140.119.4]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M26r3-1oAn5n0e1h-002VEG; Mon, 04 Jul 2022 13:19:46 +0200 In-Reply-To: (Paul Pogonyshev's message of "Sun, 3 Jul 2022 21:52:55 +0200") X-Provags-ID: V03:K1:a048jtjG92FRil+jbLcLKcGHynb52eVKmf+Plm7GSvhccMZwJL8 JGid2wv1fc2wCkzVxWwQSccDB3UW+dmTrbIYrQKexSRiBgrL+03r5UUEFG+n0VyBJHHtZYt kQGm0yf2TrZlG1cl5HSDVsLtpi9+84at3g2ydHSmj9PZSLRwaZGHrluEXLEkPXoHyDibPzx 1AKVK4Oy53XQx6UiL1dJw== X-UI-Out-Filterresults: notjunk:1;V03:K0:h1Vx4CkIH2A=:PrGW5p5mfT8yVfqGZW6UCr 17pVHaGG93PWmI2+KX89wAwlcXzJYYgsRA4ZWhrAW1WJWbXjdesfLZNPWd61lWl3/GRtXbUEa FCI1+RnKcG4J3zTnBih4R+gMiwCXTbG/pAHlhtq8XmOhaj5+/iv7TpUTPuNffq5naON3dCbEs g2Jfyt6mufgUulLDQMUKQHYxggd22wbcpiQFTfcUCnYZxPCXd9H6VT6njRh/xAXmB1y3erOZj cKtvuwlxW4p3ZiSsRmXdQ4jMUxiumaviAsspSEifeiSO3WesR1kYFSLdAF87EtFT7wZxAVwTG 39FIIZzgOl4zpd5NQvc4vEx/PavtamqlFJT330rDukoE3wZLvPIsLvm2HV+FWUAoD9h4bmpHt IVA9Iu3ZryFUsBg9+Hqo62imgzpEQhpOJRn+Qi+tJZ8x3Eoye3XVUdZ0v6iAe6KRIBePDEDLd Pvd5TjKeduQRhUyKoaDhVzzsuJrh13I+u/peXDJcKAHRmV3r9KkAZw6tJhziXSnlXNd/PB9e6 KaHAtDMszsl9ClZeeBxXBGvqmMvynwzSPeWVku2mINHkBzw2FHLWjMrhnTXd2qTDjSLMbhjmm EP/nHWAdAYgnbi7QGn+ynG4/QMVKdgYPo+MV0r4KFDpXyZbEUm+jYAr1cfMfx4Z4griimFr7Z El43jCOb3f9WfuXUK5qMK9trDC6alw28DrYN5F8crrCImHVXy50OHaXmM2ux7OLxPaJcOB2Nu /XIOar/TmxbqbWbfIovuwnonMcKNCQTPGt2Skz9yQXzXffqK2JBX4sgE0e3NMQyJxGs6G2gH 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:236051 Archived-At: Paul Pogonyshev writes: Hi Paul, >> Doing it asynchronously would require a second connection to the remote >> host. Performance would rather degrade. > > Maybe not really asynchronously, just let it return early, not waiting > for the result? I'm not sure how TRAMP receives responses, but can it > just keep executing commands sequentially, as now, but give control > back to the caller in case of commands where the result doesn't really > matter (cleanup, e.g. deleting a temporary file). Of course, this > means that if an "important" command is issued right away, it has to > wait for the response to the previous inessential command. But when > such an inessential command is the last in a batch, this waiting would > be effectively merged with Emacs' idling in the normal UI command > loop, making things more responsive for the user. Tramps communication with the remote host is like a REPL engine. It sends shell commands to the remote hosts, reads the result, and waits for the shell prompt. If it doesn't wait for the final shell prompt, it is likely that the result or the shell prompt will be seen when reading the output of the next command. This confuses. So no, I don't see a chance to implement this kind of "asynchronity". > Paul Best regards, Michael.