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#61350: Eglot over Tramp freezes with large project Date: Sat, 25 Feb 2023 15:27:36 +0100 Message-ID: <87r0udvmzr.fsf@gmx.de> References: <87y1ootw2t.fsf@gmail.com> <69968923.705640.1677163650760@office.mailbox.org> <87a613f0b7.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10870"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Thomas Koch , 61350@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 25 15:28:14 2023 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 1pVvX4-0002d1-9k for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Feb 2023 15:28:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pVvWu-0006Hj-17; Sat, 25 Feb 2023 09:28:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVvWs-0006Hb-U1 for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2023 09:28:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pVvWs-0000Qy-LN for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2023 09:28:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pVvWs-0000Mm-1O for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2023 09:28:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Feb 2023 14:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61350 X-GNU-PR-Package: emacs Original-Received: via spool by 61350-submit@debbugs.gnu.org id=B61350.16773352671383 (code B ref 61350); Sat, 25 Feb 2023 14:28:01 +0000 Original-Received: (at 61350) by debbugs.gnu.org; 25 Feb 2023 14:27:47 +0000 Original-Received: from localhost ([127.0.0.1]:39391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVvWd-0000MF-2T for submit@debbugs.gnu.org; Sat, 25 Feb 2023 09:27:47 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:41255) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVvWa-0000Ly-N3 for 61350@debbugs.gnu.org; Sat, 25 Feb 2023 09:27:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1677335257; i=michael.albinus@gmx.de; bh=HyA8fQo/+P9TLjAIfYGRjrt0hm5keHyv9GWlhBeYy3U=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=tKqZo+GxzeXEu3ZhmFJQTKjwIKuSFlWf5OVUS+Fn+o00dVuB7mLZH7TNvne2uNn9K a+UXtbJJO8vr3dAl6jfQOParPqJN/JXwPiMQcYonETyXBmbzeDZAECaU+g9w7cKt4M TcQt3QP4o2noz0D2LorEZIruEXsPttoUA/7NeKKhfdiw7P+0v3jUG1UWZgQ64+T65l YF28gtKznDWB5CitFkTcUIdqMOQO/HGvX01puT6TLvXqLN0kftNEOiEpZ+O0lNJZ5g 4dxGkfPhXSTBqFlodm0alGL5mykFL93iy1KLqKW2lsP7GCo7UeSMPUiwopEPNLGbjU U99o4D8O8ae5g== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from gandalf.gmx.de ([185.89.39.22]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MHXFr-1pJ1MO36HJ-00DTev; Sat, 25 Feb 2023 15:27:37 +0100 In-Reply-To: ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Fri, 24 Feb 2023 17:45:45 +0000") X-Provags-ID: V03:K1:S9Lvn7BU9RS5hJPZ4p8qt+1rZUu+llZ6qwf7bftq2aeUEzr4ay6 u8ZEw/2tnCFND3FkiMz5UZB4MW9miKN0IZjIDWBDkYx2Ke3h/VDcI2hNSKi/wrhGW8zXocC XcPHvFXDF1bY6eVTcZkpeJAeIe096vDkOrcIl8YaKtssz5PuYjnXab9bPGKmGNE2nHRaIlB 4Ecuf6mclAByL6nUVOx3Q== UI-OutboundReport: notjunk:1;M01:P0:KvOYFeBK8ig=;1WkMHIV4J6eqpEevtjIVTSVOgRj a8SMuG9+XBzAOZx0BtzgDnxP0hN4438RFkSZuwk+I6ODY16D3+NYHhGlXkoQvExA3rCBDcPRs liZvYeQ0m/jXXqmOzNDDATtIKbuCuZ0LLVnxEOVchRNoEcCJ0fUvFTs4Mdnfx0uuQzKRllnX5 ZxtQ1/spAzUConMQKJroClWQGRsHJwUw1eXnRXo9BFQ/S+lzL0Tivqg/05MrI7G65od6f/Z7U IdbuZux/LDtyIVR5XdUUnzkawGQJZtsXJdKXCKt7uvbp/yZPlwCnNdEl/5n6sXRfFqVtPNRBt HKdrjTms02Yh9cwJ1e6Tyv8KWKOJgwB+uD82yXvcI82p1RzwC18GmLUav3y5iJrk8okgB6jH8 dnF+TyEjmnSpRzMIqiLO1ZlUJzqnRiVHe+wp9rc9SvnlpoAL2KkxwaecNVEhjtfuib1Dt3Me7 GD7DjwIpaCMNygEL2DID8vD+OMDovGfZaxP0g5GUXQP+hvljxEXXWtmvmDiR3LoQGnrHJaVLK iSBbpH0QHQ/QQB57NsAMRxcBA8UTeO3MP9pYpI/4xrvlzLof3wD7L21g+/WB0FQrGmweab9bf ruNy0wO//XXiOTnybaEEFXTJ1CuHAzbdg+27vVRH3F8AAfJpRcQIJfKDesHj2XGb/+5dxuyEX krKim8SPBJP/4IuRU+husEZydUqfHVML8MHG1w7HHaJZJdAZBzMLkcrDS/n9HDQ6CPetV0KmY j9+npLbN8lBrtytPXtfd88c8T+vVWkeTk7i9mDjywtVG46TfA8I2xQXZZ2RwEtTdt+AsK7cs 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:256725 Archived-At: Jo=C3=A3o T=C3=A1vora writes: Hi Jo=C3=A3o, >> You don't call jsonrpc--notification-dispatcher anymore in the >> process filter directly. But calling it by a timer has the same effect: >> The process filter (accepting output) is still active, > > What exactly do you mean by "still active" and what process are you > referring to? Jsonrpc's or Tramp? Your timer is called immediately, while you're still in jsonrpc--process-filter I believe. >> > Since jsonrpc always accepts output from *all* running processes, there >> > could be (and is!) the constellation, that process output has been read >> > already, and Tramp didn't get it, waiting for the output forever. > > I could understand if we were talking C and read() here, but the process > output of other processes read by jsonrpc's call to accept-process-output > surely must have run through some filter function, it wasn't just lost > AFAIK. You've probably seen this trick a mililon times, but markers > in the process buffer is what is used commonly. It wasn't lost. The process output was retrieved and placed into the Tramp buffer, w/o Tramp's interaction. Tramp doesn't use a process filter for its own connections. The problem is rather, that Tramp must know where the output to be parsed starts in the buffer. If another process has consumed the output, even if it is pushed into the correct buffer, Tramp doesn't know. >> Again, I still believe we need a general solution in Tramp, using thread= s. > > I don't understand what is conceptually impossible (or very hard) to > achieve with evented IO like we have in Emacs. I've tried different patches, mainly in tramp-accept-process-output. It improves the situation a little bit, but not reliably. Sometimes the test works, sometimes it blocks. And even if it doesn't block, a while later we run into the "Forbidden reentrant call of Tramp" error. Honestly, I still don't understand really what's up. Let's see whether adding threads to Tramp helps. Best regards, Michael.