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

[Philipp Stephani]

Am Sa., 26. Dez. 2020 um 13:16 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > Date: Sat, 26 Dec 2020 14:08:11 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > 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.