GNU bug report logs - #26397
25.1; call-process slow on macOS and slower on larger frames

Previous Next

Package: emacs;

Reported by: Aaron Jensen <aaronjensen <at> gmail.com>

Date: Sat, 8 Apr 2017 06:26:02 UTC

Severity: normal

Tags: fixed

Found in version 25.1

Fixed in version 26.1

Done: Alan Third <alan <at> idiocy.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Alan Third <alan <at> idiocy.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 26397 <at> debbugs.gnu.org, YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: bug#26397: 25.1; call-process slow on macOS and slower on larger frames
Date: Sun, 9 Apr 2017 14:01:55 +0100
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 <at> 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




This bug report was last modified 3 years and 199 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.