[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#26397: 25.1; call-process slow on macOS and slower on larger frames
From: |
Alan Third |
Subject: |
bug#26397: 25.1; call-process slow on macOS and slower on larger frames |
Date: |
Sun, 9 Apr 2017 14:01:55 +0100 |
User-agent: |
Mutt/1.7.2 (2016-11-26) |
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
- bug#26397: 25.1; call-process slow on macOS and slower on larger frames, Aaron Jensen, 2017/04/08
- bug#26397: 25.1; call-process slow on macOS and slower on larger frames, YAMAMOTO Mitsuharu, 2017/04/08
- bug#26397: 25.1; call-process slow on macOS and slower on larger frames, Aaron Jensen, 2017/04/08
- bug#26397: 25.1; call-process slow on macOS and slower on larger frames, Alan Third, 2017/04/08
- bug#26397: 25.1; call-process slow on macOS and slower on larger frames,
Alan Third <=
- bug#26397: 25.1; call-process slow on macOS and slower on larger frames, Aaron Jensen, 2017/04/09
- bug#26397: [PATCH] Use vfork if possible on Darwin (bug#26397), Alan Third, 2017/04/09
- bug#26397: [PATCH] Use vfork if possible on Darwin (bug#26397), Andreas Schwab, 2017/04/09
- bug#26397: [PATCH] Use vfork if possible on Darwin (bug#26397), Alan Third, 2017/04/09
- bug#26397: [PATCH] Use vfork if possible on Darwin (bug#26397), YAMAMOTO Mitsuharu, 2017/04/09
- bug#26397: [PATCH] Use vfork if possible on Darwin (bug#26397), Aaron Jensen, 2017/04/09
- bug#26397: [PATCH] Use vfork if possible on Darwin (bug#26397), YAMAMOTO Mitsuharu, 2017/04/09
- bug#26397: [PATCH] Use vfork if possible on Darwin (bug#26397), Aaron Jensen, 2017/04/10
- bug#26397: [PATCH v2] Use vfork if possible on Darwin (bug#26397), Alan Third, 2017/04/10
- bug#26397: [PATCH v2] Use vfork if possible on Darwin (bug#26397), YAMAMOTO Mitsuharu, 2017/04/11