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:43:07 +0100 Message-ID: References: <835z4qnhyx.fsf@gnu.org> <83y2hklqhg.fsf@gnu.org> <83wnx4lq3b.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="24267"; 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:44: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 1kuI6g-0006BR-Vs for ged-emacs-devel@m.gmane-mx.org; Tue, 29 Dec 2020 17:44:22 +0100 Original-Received: from localhost ([::1]:40440 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kuI6g-0000fI-2h for ged-emacs-devel@m.gmane-mx.org; Tue, 29 Dec 2020 11:44:22 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43826) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kuI5m-00005G-Nl for emacs-devel@gnu.org; Tue, 29 Dec 2020 11:43:32 -0500 Original-Received: from mail-oi1-x22c.google.com ([2607:f8b0:4864:20::22c]:41379) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kuI5h-00036p-97; Tue, 29 Dec 2020 11:43:26 -0500 Original-Received: by mail-oi1-x22c.google.com with SMTP id 15so15148606oix.8; Tue, 29 Dec 2020 08:43:19 -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=VtxR8/UMHKl1e/x43IPNY2crZaT1wTAlTKYY7NBcZ0E=; b=aekWvSj5GwEe+2+XNkl0y3G1RoFZgbxfRLfpfWgOKZrwh7QgH/PpLx9pOy8Mej9lxt i1dP/T1UVZYdCE1rZMhN+O9J6N5dM6wlRj9QuSlUc4sQU0fctPxlwoFw2b7j3td1aU9/ kI2PFDLz4rabiTC0eZN2hHNwjzkJIulg9wj5sbc5QqwSiiEIasaeE0mprYSNj5v4MzkR 9teFwLesHaccL1ayhBJiloi+Bp7hHihixPT4tDTsAyVPfTrqIzItSzz9BUgv2rWqDmaS nxQRnescFDU5V/ok7MI0VSaxclEMPFW0sy/3F7pK08G4bYwH4mvvAWMGDBOwDluk5YTe cFTg== 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=VtxR8/UMHKl1e/x43IPNY2crZaT1wTAlTKYY7NBcZ0E=; b=FCCf6nx0cKUyTIhKmrVwkM3mbWLPChcHIBp6b6VzVftQJrkPkzT+Hcj1a6NCK5jUJ8 9WBIC0KrLRtYq6ncxe5xtnG/8Cwf1RovV+Bzl1dHyv/eHiZLj5kqgQEmgnkenki5JzHK 69/Fyw9Jr3rvUJjny7QN1QVwWyuamHgFD5snrH0eFVZXA0Lo4MuFzIe6S2jQbUBMCOBb AYYR5MVhLSEStHitn4+pKz3KgqjT/9Vkr20WFsBZ247XAHR3bhjMl8qNMYzR3yilbhwF Ok0ZhEzez5UAVrPVEjYPTYA5FeVkut5gkK7PttO3Nnu7C6aOVob939J0X3ammuxXAPXB qrZQ== X-Gm-Message-State: AOAM531TABB3v28ygFxf9x+ngzziYeFIeRtbD4cPX5zdvKPeLZytoB1b NAI3qrQNjQK2kQkhK3abbvFT21Zq0iPM6vf1MjAc/DyAXOfQ0g== X-Google-Smtp-Source: ABdhPJyll3BKtoU0+DuoquQQC1C+ipX9iXzGfA0HpW4IjmiTvQlzXBFH1zdG3EQ/oAHt9ECkFr5dwJwn+B6GHbum5c4= X-Received: by 2002:aca:3b03:: with SMTP id i3mr2845844oia.170.1609260198196; Tue, 29 Dec 2020 08:43:18 -0800 (PST) In-Reply-To: <83wnx4lq3b.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::22c; envelope-from=p.stephani2@gmail.com; helo=mail-oi1-x22c.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:262073 Archived-At: Am Sa., 26. Dez. 2020 um 13:16 Uhr schrieb Eli Zaretskii : > > > Date: Sat, 26 Dec 2020 14:08:11 +0200 > > From: Eli Zaretskii > > Cc: emacs-devel@gnu.org > > > > 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.) > > Btw, given this condition for using posix_spawn: > > + /* `posix_spawn' doesn't yet support setting up pseudoterminals, so > + we fall back to `vfork' if we're supposed to use a > + pseudoterminal. */ > + > + bool use_posix_spawn = can_use_posix_spawn && pty == NULL; > > I understand that the absolute majority of subprocesses on GNU and > Posix platforms will not use posix_spawn, because we usually do use > PTYs? If so, one wonders why it is a good idea to complicate our code > and make it more dependent on Gnulib, for such small gains? Should we > perhaps wait until posix_spawn does support PTYs? I think posix_spawn supports TTYs well enough by now. From what I see in the code we perform 5 TTY-related actions between fork and exec: 1. setsid. This is now supported by posix_spawn at least on GNU/Linux and macOS, and IIUC will be in the next POSIX standard. 2. Making the TTY the controlling terminal of the process. IIUC we first try using TIOCSCTTY, and then opening the TTY file without O_NOCTTY. On GNU/Linux, the former one probably fails because stdin is -1. So we could only do the latter one, which is supported by posix_spawn (since it's just opening a file). 3. Some terminal setup (setting attributes, loading a line discipline, etc.). We should be able to do that in the parent process as well, assuming we can define USG_SUBTTY_WORKS (see below). 4. setpgid. That shouldn't be necessary and probably actually fails due to the setsid before. 5. tcsetpgrp. That also shouldn't be necessary, because after the setsid, we have a single process in a single process group in the session. I experimented (on GNU/Linux) with posix_spawn for TTYs as well, and it seems to work fine (I played around with M-x term a bit). One thing that I'm wondering about is the comment in process.c: /* On most USG systems it does not work to open the pty's tty here, then close it and reopen it in the child. */ That's an old comment, and I'm not sure it's true any more. When patching configure.ac so that it defines USG_SUBTTY_WORKS on GNU/Linux as well, then everything still seems to work fine.