emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master 2c79a8f 2/2: Use posix_spawn if possible.


From: Saulius Menkevičius
Subject: Re: master 2c79a8f 2/2: Use posix_spawn if possible.
Date: Sat, 29 Jan 2022 10:03:53 +0200

I did not register it yet. I was thinking about making a reduced test suite for 
this (small dotnet app+emacs code) to replicate the issue first.

And then I am waiting for a M1 MacBook to have shipped to me to test if the 
commit to switch to posix_spawn broke just Linux or macOS too. I have reports 
of x64/Linux breakage only at this point.

—Saulius Menkevičius

> Am 2022-01-28 um 19:12 schrieb Matt Armstrong <matt@rfc20.org>:
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> Date: Tue, 25 Jan 2022 14:25:23 +0200
>>> From: Saulius Menkevicius <sauliusmenkevicius@fastmail.com>
>>> Cc: p.stephani2@gmail.com, alan@idiocy.org, mituharu@math.s.chiba-u.ac.jp,
>>> emacs-devel@gnu.org
>>> 
>>> I certainly cannot answer that, it probably does some kind of sniffing 
>>> on FDs and changes behaviour.
>>> 
>>> To actually figure that out I would need to build a minimal test fixture 
>>> for this bug/issue and submit to dotnet/runtime repo on github for them 
>>> to check and/or fix it.
>> 
>> I think there's no way around this.  We need at least to understand
>> what part of posix_spawn code interferes with pipe-based I/O used by
>> these LSP servers, and why.
> 
> I don't find an emacs bug filed for this issue.  Saulius, it would be
> good to file one.
> 
> This issue tickled a memory I had of Python moving away from posix_spawn
> due to various portability issues: https://bugs.python.org/issue35823.
> The issues they ran into and solved may inform this investigation.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]