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

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?