Robert you are correct about ``:connection-type''. In particular lsp-mode specifies ``:connection-type pty'' here:

- https://github.com/emacs-lsp/lsp-mode/blob/master/lsp-mode.el#L6932 <https://github.com/emacs-lsp/lsp-mode/blob/master/lsp-mode.el#L6932>

As a workaround fsharp/csharp language servers can use shell wrapper for launching the server binaries, as "#!/bin/bash" will apparently normalize signal mask before launching sub-subprocess and things work alright from thereon.

This is not as nice as having things just working before this change to `make-process`, but at least we have some way to work around this issue..

-Saulius

> Am 2022-02-08 um 16:59 schrieb Robert Pluim <rpluim@gmail.com>:
> 
>>>>>> On Tue, 8 Feb 2022 14:18:43 +0200, Saulius Menkevicius <sauliusmenkevicius@fastmail.com> said:
> 
>    Saulius> I believe this is not a problem related to C#/dotnet but generally
>    Saulius> with how signals are blocked on child processes launched with
>    Saulius> posix_spawn in the current implementation.
> 
> (I could argue that if dotnet wants to ensure it receives SIGCHLD, it
> should unblock it itself, but thatʼs a different discussion, we
> definitely have an Emacs bug)
> 
> And come to think of it, the posix_spawn code path is only exercised
> when not asking for a pseudo tty. Since the default value for
> `process-connection-type' is t => pty, Iʼm assuming that the elisp
> code in question is binding that to nil, or using the :connection-type
> argument to `make-process'.
> 
> Would it be possible to test using ptys? If that works thatʼs a
> workaround that requires no changes to emacs-28.
> 
> Thanks
> 
> Robert
> --