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

[Eli Zaretskii <eliz@gnu.org>]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sat, 26 Dec 2020 12:26:24 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > If you cannot make sure Emacs still builds on all supported platforms,
> 
> Hmm, that's indeed a rather challenging request. Don't we support like
> dozens of platforms, including several nonfree operating systems?

No, I mean only the main ones: GNU/Linux, some *BSD, macOS,
MS-Windows.

> How do others deal with this? Do people run Windows VMs and try to
> build Emacs on them before pushing?

Sometimes, yes.  Other times, users of those systems are requested to
text the patch before landing it.

But many of the breaking changes can be found by simple inspection.
For example, in the case in point, if we are not going to use
posix_spawn on MS-Windows, we need to augment nt/mingw-cfg.site and/or
nt/gnulib-cfg.mk to avoid compiling the respective Gnulib modules,
since doing that just risks causing trouble (as happened in this
case).  Also, since you deduced (correctly) that the Gnulib
posix_spawn module cannot be used on MS-Windows, it isn't enough to
have a run-time condition for bypassing that, you need to #ifdef away
the relevant code, because otherwise Emacs might fail to link for no
good reason.

> > please either post your patches first, or push them to a scratch
> > branch, and ask people who have access to those platforms to test it
> > before the changes land on master.
> 
> OK, I've now done that (branch scratch/posix-spawn).

Thanks.  Would people please try that on various platforms and report
any problems?

> > Btw, regarding use of posix_spawn, I'd expect a discussion before we
> > make such a change.  AFAIU it is not a trivial decision, as
> > posix_spawn has its down sides, and therefore is not necessarily the
> > best API for running sub-processes on every supported platform, even
> > if you consider only the Posix ones.  We should consider the
> > advantages and disadvantages before we make the decision.
> 
> Sure, I'm happy to have that discussion. I briefly reviewed the
> posix_spawn implementation of GNU libc and Gnulib, and found that it
> uses vfork/clone + execve like our hand-rolled code, so I wouldn't
> expect any significant change. The primary advantage is to offload
> complexity into a library that can properly deal with system-specific
> issues and can improve over time. For example, on Linux, posix_spawn
> can use clone instead of vfork.

See Savannah bug #59093 for one subtle issue:

  https://savannah.gnu.org/bugs/?59093

Since Emacs also sets its stack limit in some cases, this could be
directly relevant to us.  (But I didn't look into it close enough to
tell whether it actually is relevant.)

> On Windows, posix_spawn could directly call CreateProcess (though
> Gnulib doesn't implement that yet).

FYI: there's a general problem with using Gnulib code on MS-Windows
for anything in Emacs that involves file names.  Emacs on MS-Windows
uses UTF-8 encoded file names, which allows us to support 'char *'
strings as file names outside of the domain of the current system
codepage.  This works by basically wrapping any API that accepts file
names with our own code that converts file names to UTF-16, and then
invokes Windows APIs which accept 'wchar_t *' "wide" strings.  Gnulib
doesn't have this feature, it just calls Windows APIs assuming the
'char *' strings as file names will be correctly interpreted -- which
doesn't work with UTF-8 encoded file names.

Running subprocesses definitely manipulates file names, so the above
issue is very relevant here.