bug#26397: 25.1; call-process slow on macOS and slower on larger frames

[Alan Third <alan@idiocy.org>]

On Sat, Apr 08, 2017 at 08:19:59PM +0100, Alan Third wrote:
> On Sat, Apr 08, 2017 at 08:47:25AM -0700, Aaron Jensen wrote:
> > On Sat, Apr 8, 2017 at 12:37 AM, YAMAMOTO Mitsuharu
> > <mituharu@math.s.chiba-u.ac.jp> wrote:
> > >
> > > Probably "fork" copies some GUI resources.  That would also explain
> > > why the performance is worse on the Mac port, where each frame
> > > allocates an extra NSWindow for overlaying.
> > >
> > > It becomes much faster and seemingly unaffected by the frame size if
> > > you comment out "#undef HAVE_WORKING_VFORK" and "#define vfork fork"
> > > in src/conf_post.h.  But I'm not sure if it is safe.
> >
> > Wow, that does make a big difference. The comment says that Emacs
> > hangs when evaluating:
> > 
> > (make-comint "test0" "/nodir/nofile" nil "")
> > 
> > But I can not reproduce that currently with vfork.

I can’t reproduce a hang with that command either.

> > I do not understand the second comment: "Also, setsid is not
> > allowed in the vfork child's context as of Darwin 9/Mac OS X
> > 10.5."
> 
> It looks to me like we could replace the call to setsid with
> 
>     setpgid (0, 0);
> 
> for Darwin builds.

No, forget that. It doesn’t do the same thing at all.

If you run Emacs, then

    M‐x ansi-term RET RET

You should get a shell prompt. Using fork/setsid, your shell will be
able to do job control, but using vfork it can’t. You can test this by
typing the `bg` command. Zsh (and I assume bash, etc.) responds by
telling you either there are no jobs, or that the shell has no job
control.

We could work around this in a rather ugly manner by doing something like:

#ifdef DARWIN_OS
  if (pty_flag)
    pid = fork ();
  else
    pid = vfork ();
#else
  pid = vfork ();
#endif

which would use fork where we’re expecting to run setsid, and vfork
otherwise.

-- 
Alan Third