From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jostein_Kj=c3=b8nigsen?= Newsgroups: gmane.emacs.devel Subject: Re: master 2c79a8f 2/2: Use posix_spawn if possible. Date: Tue, 25 Jan 2022 12:46:41 +0100 Message-ID: References: <7CFD5E28-8266-4004-BF66-255146D72722@gnu.org> Reply-To: jostein@kjonigsen.net Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------eUwJafpcD0Sk0m89jRBpyjsj" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36823"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Cc: =?UTF-8?Q?Saulius_Menkevi=c4=8dius?= To: emacs-devel@gnu.org, Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 25 12:47:36 2022 Return-path: Envelope-to: ged-emacs-devel@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 1nCKIQ-0009LZ-18 for ged-emacs-devel@m.gmane-mx.org; Tue, 25 Jan 2022 12:47:36 +0100 Original-Received: from localhost ([::1]:45110 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nCKIO-0005Wi-AT for ged-emacs-devel@m.gmane-mx.org; Tue, 25 Jan 2022 06:47:32 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50094) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCKHi-0004Zm-MS for emacs-devel@gnu.org; Tue, 25 Jan 2022 06:46:50 -0500 Original-Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:38255) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCKHg-0005Ap-2c; Tue, 25 Jan 2022 06:46:50 -0500 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 1C110320212E; Tue, 25 Jan 2022 06:46:44 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 25 Jan 2022 06:46:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= secure.kjonigsen.net; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:sender:subject:subject:to:to; s=fm2; bh=6Y+wc ad4+Kut5Gyin1O/qby1YxAVA5RXaJbIy7uZRL8=; b=iMsv/XCp+d00BSRKbKISi hzZQnxUUp+Yj/hinTwUsP/7E/dH/VgCOFDxB+Gqsw7ELosVnezoWEeenNAFo4cS4 SfKxCR2Ei6OAvHL1IrznPpFCqfxQRjf3IAIU6fWX92iVhz+2q3MjATdhfJQ3TPIp 3V+C4W0kQsP59n7BREl65jmvv3171v6awAzA0mYaiD86Oi/XhPTNKe5J30YXNB62 uw0UIG7U2zzFSjwD0idl07glwYxFms9nwjY7Qoguhk6CwGjzBEBtN+tLBPy1apIh 5XA9IKqfU5C3+pq07spcaCNQRwgUBvI5f9RJlK+NuMbtKitNjPehcNusk9brbXGF A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=6Y+wca d4+Kut5Gyin1O/qby1YxAVA5RXaJbIy7uZRL8=; b=PjrbR11C9i6JVWCVYJLmcM p6XwxxSZMEFO6rQRGG8eMSUd1PoGVFUkHKmz2Hs7fIkWm9NmKTflYvpw0kMOz4Kz OSaO7Emz5H5HQUg6I5YqYEdr0P2bfJjy6x/xbC9lY1u6cbZ5vdIhYxSiNuVxozdM 0TF5hMq8vCYzzHGRaLMRC+jeUrQSL4VW2ZqVgmfKtA7xNKpcBeHanFT4dufF65en ivoKL7wSAvTdnncqKyiJ1WUgho7Rgkr/53EoGTP9Pm2V8635Uj4gxQNM/G2XEFxE nsOfWIQTHro9qg76kISOxlNSmt1c9bn4COU8B+2KKJ6rEzvBY3N6VMeEr//Q3dwQ == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrvdelgdefudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtkfffgggfrhfuvfhfhfgjsegrtderredtfeejnecuhfhrohhmpeflohhsthgv ihhnpgfmjhppnhhighhsvghnuceojhhoshhtvghinhesshgvtghurhgvrdhkjhhonhhigh hsvghnrdhnvghtqeenucggtffrrghtthgvrhhnpedvfeeufeegffetffdvvddvteelkeel veduleehhffffeeuhfetteeukeegudejgeenucffohhmrghinhepfihithhhrdhnvghtpd hthhgvrdhnvghtpdhgihhthhhusgdrtghomhdpkhhjnhhighhsvghnrdhnohenucevlhhu shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjohhsthgvihhnse hsvggtuhhrvgdrkhhjohhnihhgshgvnhdrnhgvth X-ME-Proxy: Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 25 Jan 2022 06:46:42 -0500 (EST) Content-Language: en-GB In-Reply-To: Received-SPF: pass client-ip=64.147.123.19; envelope-from=jostein@secure.kjonigsen.net; helo=wout3-smtp.messagingengine.com X-Spam_score_int: -26 X-Spam_score: -2.7 X-Spam_bar: -- X-Spam_report: (-2.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:285353 Archived-At: This is a multi-part message in MIME format. --------------eUwJafpcD0Sk0m89jRBpyjsj Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Like Saulius says, this is fairly technical and far above at least my head. I still think it's worth discussing if we *need* this change for Linux. When the original commit was landed, (from what I can tell) it was because it was needed for Mac, and assumed harmless for other platforms. The merge to master was then meant as a testing-ground to see if it would cause issues. And well.. Here's at least one issue :) For perspective, over the last couple of years, Emacs as a editor/platform to work with .NET has improved tremendously to the point that Emacs is my primary editor for anything .NET. It would be a shame to see that completely break on Emacs 29, and being forced to use VSCode to get work done. As things stand now, I think it sounds easier to revert this change (for Linux only) than trying to convince Microsoft to change the .NET runtime to better interop with Emacs on Linux :) My 2 cents. -- Kind regards Jostein Kjønigsen On 25.01.2022 09:58, Saulius Menkevicius wrote: > Sorry I did not mention the platform, this happens on Linux/x64 and > has been reported by multiple persons: > > - https://github.com/razzmatazz/csharp-language-server/issues/12 > > > The issue has been noticed when dotnet-based LSP servers are used with > emacs/lsp-mode, -- in particular lsp-mode starts the server using > `make-process` and then communicates over stdio. Link to the code that > launches the server: > > - https://github.com/emacs-lsp/lsp-mode/blob/master/lsp-mode.el#L6925 > > > We have csharp-ls and fsac servers launched with the same mechanism as > are for other languages -- which are working ok with posix_spawn > enabled. It only breaks for those before-mentioned LSP servers that > are implemented on top of dotnet and use dotnet runtime (same thing as > JVM, but for C#/F#/CLR languages). > > Now it appears, that switch to posix_spawn broke communication over > stdio to those dotnet-based LSP servers for some technical reason, -- > I didn't investigate yet why, because it is a bit over my head. I > *think* there is an interplay between posix_spawn-based process launch > implementation in emacs and dotnet runtime stdio abstractions/platform > layer -- because otherwise other language servers work with that > commit that enables posix_spawn, like those based on JVM too. > > > I know this is a bit of a corner case as posix_spawn brings > performance benefits, but just FYI. > > BR, > > -Saulius Menkevicius > > > Am 25.01.22 um 10:41 schrieb Eli Zaretskii: >> On January 25, 2022 8:48:12 AM GMT+02:00, Saulius Menkevicius >> wrote: >>> Hi, >>> >>> I know this has been merged a couple of months ago to `master` but I >>> would like to report breakage that occurs due to that commit. >>> >>> We have csharp-ls (C#) and fsautocomplete (F#) LSP servers that stopped >>> working with that commit (git-bisected to >>> a60053f8368e058229721f1bf1567c2b1676b239). >>> >>> I did not delve too much into the details or prepare a minimal test >>> case >>> but this appears to be an interplay between dotnet runtime (v6) and >>> posix_spawn. >>> >>> Not sure if that warrants a revert but just a heads-up. >> Can you explain how dotnet runtime comes into play here?  Does Emacs >> invoke a dotnet process or something? >> >> And on what OS does this happen? > -- Vennlig hilsen *Jostein Kjønigsen* jostein@kjonigsen.net 🍵 jostein@gmail.com 🍵 jostein@hufleslufs.no https://jostein.kjønigsen.no --------------eUwJafpcD0Sk0m89jRBpyjsj Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Like Saulius says, this is fairly technical and far above at least my head.

I still think it's worth discussing if we *need* this change for Linux. When the original commit was landed, (from what I can tell) it was because it was needed for Mac, and assumed harmless for other platforms. The merge to master was then meant as a testing-ground to see if it would cause issues.

And well.. Here's at least one issue :)

For perspective, over the last couple of years, Emacs as a editor/platform to work with .NET has improved tremendously to the point that Emacs is my primary editor for anything .NET. It would be a shame to see that completely break on Emacs 29, and being forced to use VSCode to get work done.

As things stand now, I think it sounds easier to revert this change (for Linux only) than trying to convince Microsoft to change the .NET runtime to better interop with Emacs on Linux :)

My 2 cents.

--
Kind regards
Jostein Kjønigsen

On 25.01.2022 09:58, Saulius Menkevicius wrote:
Sorry I did not mention the platform, this happens on Linux/x64 and has been reported by multiple persons:

- https://github.com/razzmatazz/csharp-language-server/issues/12


The issue has been noticed when dotnet-based LSP servers are used with emacs/lsp-mode, -- in particular lsp-mode starts the server using `make-process` and then communicates over stdio. Link to the code that launches the server:

- https://github.com/emacs-lsp/lsp-mode/blob/master/lsp-mode.el#L6925


We have csharp-ls and fsac servers launched with the same mechanism as are for other languages -- which are working ok with posix_spawn enabled. It only breaks for those before-mentioned LSP servers that are implemented on top of dotnet and use dotnet runtime (same thing as JVM, but for C#/F#/CLR languages).

Now it appears, that switch to posix_spawn broke communication over stdio to those dotnet-based LSP servers for some technical reason, -- I didn't investigate yet why, because it is a bit over my head. I *think* there is an interplay between posix_spawn-based process launch implementation in emacs and dotnet runtime stdio abstractions/platform layer -- because otherwise other language servers work with that commit that enables posix_spawn, like those based on JVM too.


I know this is a bit of a corner case as posix_spawn brings performance benefits, but just FYI.

BR,

-Saulius Menkevicius


Am 25.01.22 um 10:41 schrieb Eli Zaretskii:
On January 25, 2022 8:48:12 AM GMT+02:00, Saulius Menkevicius <sauliusmenkevicius@fastmail.com> wrote:
Hi,

I know this has been merged a couple of months ago to `master` but I
would like to report breakage that occurs due to that commit.

We have csharp-ls (C#) and fsautocomplete (F#) LSP servers that stopped
working with that commit (git-bisected to
a60053f8368e058229721f1bf1567c2b1676b239).

I did not delve too much into the details or prepare a minimal test case
but this appears to be an interplay between dotnet runtime (v6) and
posix_spawn.

Not sure if that warrants a revert but just a heads-up.
Can you explain how dotnet runtime comes into play here?  Does Emacs invoke a dotnet process or something?

And on what OS does this happen?

--
Vennlig hilsen
Jostein Kjønigsen

jostein@kjonigsen.net 🍵 jostein@gmail.com 🍵 jostein@hufleslufs.no
https://jostein.kjønigsen.no
--------------eUwJafpcD0Sk0m89jRBpyjsj--