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).