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: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 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. However I can’t tell for sure if that function is
allowed after vfork, as I can’t even find any official reference to
setsid not being allowed.

I’m probably just not looking hard enough.

It seems the ‘correct’ solution for macOS is to use posix_spawn
instead of (v)fork/exec, but that would probably require a larger
change, and Daniel Colascione seems to have looked into it before, and
come across this very issue:

https://lists.gnu.org/archive/html/emacs-devel/2012-01/msg00078.html

He doesn’t seem to have got an answer, though, and Emacs no longer
falls back to setpgid on any platform (see commit
dd0333b6155c9c3aabdac9418c005e2e5b4796e7).

> How might I test that?

The call to setsid is inside an `if` that’s to do with ptys. I suspect
it must come into play if you’re using Emacs in a text terminal,
rather than as a GUI app. I can’t check this just now as my master
won’t build...

-- 
Alan Third