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

[Reuben Thomas <rrt@sc3d.org>]

[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]

On 20 March 2014 03:45, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Wed, 19 Mar 2014 21:14:22 +0000
> > From: Reuben Thomas <rrt@sc3d.org>
> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Andreas Schwab <
> schwab@linux-m68k.org>,
> >       17036@debbugs.gnu.org
> >
> > > 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

[-- Attachment #2: Type: text/html, Size: 3263 bytes --]