Subject: bug#17036: Continuation for Emacs: invoking a process on exit?

From: Reuben Thomas <[email-masked]>
Date: Thu, 20 Mar 2014 12:02:49 +0000

On 20 March 2014 03:45, Eli Zaretskii <[email-masked]> wrote:

> > Date: Wed, 19 Mar 2014 21:14:22 +0000
> > From: Reuben Thomas <[email-masked]>
> > Cc: Stefan Monnier <[email-masked]>, Andreas Schwab <
> [email-masked]>,
> >       [email-masked]
> >
> > > Don't believe the sales people.  MS's execvp is buggy, and even if we
> > > forget about those bugs, it won't do what is expected here: it won't
> > > keep the file descriptors open in the original process still open in
> > > the overlaid process.  That's because there's no 'exec' system call on
> > > Windows, so execvp is _emulated_: the original process simply invokes
> > > the new one as its child process, and then immediately exits.
> > >
> >
> > That's good enough for restart-emacs.
>
> Maybe so, it's hard to say, since you never described what that should
> do.
>

I didn't discuss the command (it was Glenn Morris who suggested the name),
but in my original bug report I said: "This would be useful for restarting
having updated my configuration...as it would save having manually to issue a
new 'emacs' command..." For this, a simple "exec emacs" is enough, but why
not throw in command-line arguments too.

>  I very much doubt that this limitation would not render the whole
> issue moot on Windows.  E.g., how will restart-emacs then be different
> from a simple call-process?

Because Emacs does not continue running after it exits. As I said in my
second email to this bug: "...to reexec Emacs, it needs to be a proper exec
[so that] Emacs has[...] finished shutting down when it runs."

If you simply use CallProcess (or fork/exec on POSIX systems), then the
newly-started emacs will be in contention with the old one, even if the old
one has nearly finished exiting.

>  But again, since you didn't say what the
> feature is supposed to do, ...
>

A tail-call, but for processes. (BTW, sorry to have mentioned call/cc
earlier, that was a bad analogy.)

-- 
http://rrt.sc3d.org