From mboxrd@z Thu Jan 1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Philipp Stephani
Newsgroups: gmane.emacs.devel
Subject: Re: master 2c79a8f 2/2: Use posix_spawn if possible.
Date: Tue, 29 Dec 2020 17:29:59 +0100
Message-ID:
References: <835z4qnhyx.fsf@gnu.org>
<83y2hklqhg.fsf@gnu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
logging-data="11637"; mail-complaints-to="usenet@ciao.gmane.io"
Cc: Emacs developers
To: Eli Zaretskii
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 29 17:32:23 2020
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 1kuHv5-0002u4-Kq
for ged-emacs-devel@m.gmane-mx.org; Tue, 29 Dec 2020 17:32:23 +0100
Original-Received: from localhost ([::1]:57958 helo=lists1p.gnu.org)
by lists.gnu.org with esmtp (Exim 4.90_1)
(envelope-from )
id 1kuHv4-0003S3-Iu
for ged-emacs-devel@m.gmane-mx.org; Tue, 29 Dec 2020 11:32:22 -0500
Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41582)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from )
id 1kuHt0-0002ug-44
for emacs-devel@gnu.org; Tue, 29 Dec 2020 11:30:14 -0500
Original-Received: from mail-oo1-xc29.google.com ([2607:f8b0:4864:20::c29]:43242)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from )
id 1kuHsy-00014T-Hb; Tue, 29 Dec 2020 11:30:13 -0500
Original-Received: by mail-oo1-xc29.google.com with SMTP id y14so2934159oom.10;
Tue, 29 Dec 2020 08:30:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=w+jidC1xCXnkgmP30wD1HgU1jJQhlFZ+wMImvJvlgeg=;
b=BoDeKJi0P2c6UKZ7zOOyAZEgpa3O2TZerMwOlyJYP4yLoSlZE3Qnfx4CDKpHfsb/MV
jHsnCaVi97xMf7PV+lLnWL5DIfuqRLt9QRPgTA5u3Rb9YJcyaSzc6S1SbwwXrdbURf3H
NxE4eIZBnHIBNQQYoFdaHWzl5M9pzVPBGbaTHymhNL6XwGSxJhBMdDhmiuv6TVPeY4PX
YZ0KwTE+oBzF+t69kKT5MMVgPI83/YKEe3ytSj0sk8vwE/0rL/fJhS33ccqxj/kXMSvF
VjniHLWWG4dim9qACie94MMEyQBllKE7vlJsf+olOWYwHXLcY57Ii04Ed7NvcFq4pemB
6KwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=w+jidC1xCXnkgmP30wD1HgU1jJQhlFZ+wMImvJvlgeg=;
b=KV1yPhdpS3KZ0b9Vm2d8y9tYQOSkw5FcRLwfng40tBVRt5fLqPijM6vnVwUyqc6w3+
2bmGHT0OJ+zOD0AGwJfSzy92kNd3w9DBt27GI+j7Hza9IQxjUXYZMO7z08/d1K82YbAa
pgGJnOabHctb8pNrp1PauTmkRToHGbAwyoRczWv5H7nhCgeZBNYYsDUvamSEYvlaIXhN
75V4cbihoT3XFX6e62Kx3fWysvcWSR70UGOPiEG8XuIzN+tmCQJBYd+KexR3xVYIG+pz
PPSHWuAvg3jV5nHTcMc5+wM4CHu1Xchn1vSV1xZN7ev4evyqOOQjyseUdySHNuPdP9xj
sffA==
X-Gm-Message-State: AOAM530Lt6tMiBpnvugUCrz1MFttSJd30ylqNaSD96TZJqfVj8t82JGL
ijJSzCdxioVkckn8nurbEfazouqQm7Oht0H/3aqj1kCEefoYgA==
X-Google-Smtp-Source: ABdhPJzI3gqLOBLR+BTcKkW1HbbUOOnM2P0sMt16BGK7r00nJ2qnUmOJCr809WBDR5RhzXnAt2lEflvNW9QyXjO76UM=
X-Received: by 2002:a4a:97a3:: with SMTP id w32mr34086559ooi.81.1609259410500;
Tue, 29 Dec 2020 08:30:10 -0800 (PST)
In-Reply-To: <83y2hklqhg.fsf@gnu.org>
Received-SPF: pass client-ip=2607:f8b0:4864:20::c29;
envelope-from=p.stephani2@gmail.com; helo=mail-oo1-xc29.google.com
X-Spam_score_int: 1
X-Spam_score: 0.1
X-Spam_bar: /
X-Spam_report: (0.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25,
FREEMAIL_FROM=0.001, PDS_OTHER_BAD_TLD=1.997, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.23
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:262072
Archived-At:
(I'm still trying to set up some emulated Windows installation, but
haven't really been successful so far.)
Am Sa., 26. Dez. 2020 um 13:08 Uhr schrieb Eli Zaretskii :
>
> 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.
Gnulib provides a stub definition for posix_spawn on Windows as well
(in fact, as of a few days ago, it provides a non-stub
implementation), so linking shouldn't fail. Also compiling the stub
implementation on Windows shouldn't hurt; if it's never called the
linker will likely remove the stub.
What error messages do you see on Windows when trying to build the branch?
> > > 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.)
I think that specific problem isn't relevant (we don't change the
stack size between fork and exec), but the fix to
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24869 (ironically
reported by me) is.
As indicated in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24869#8,
it might be better to solve the underlying problem in a different way
that doesn't involve changing resource limits (changing a
process-global setting is somewhat fishy anyway, especially with
modules). Essentially we just need to make sure to not add file
descriptors larger than FD_SETSIZE to an fd_set.
>
> > 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.
Agreed. It would be really nice if Gnulib adopted the Emacs approach
(probably hidden behind some flag).