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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: rgm@gnu.org,  17036@debbugs.gnu.org,  schwab@linux-m68k.org,  rrt@sc3d.org
> Date: Sun, 17 Apr 2022 14:49:23 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >   . when kill-emacs is called with RESTART non-nil, the value of ARG
> >     is ignored; this should at least be documented;
> 
> Emacs doesn't exit, so I thought it would be self-evident that ARG
> (which is all about the exit code) is ignored.

Let's see how evident is it ;-)

> >   . the exit status of the restarted Emacs is discarded, so it will
> >     not be available to the parent program, at least on MS-Windows,
> >     and also if execvp fails for some reason;
> 
> Again, Emacs doesn't exit, so...

I meant when the restarted Emacs exits.  It _can_ exit, can't it?

> >   . the semantics of the file descriptors open in the original Emacs
> >     process is not clear to me: will they remain open in the restarted
> >     Emacs, if the original Emacs opened them without CLOEXEC?
> 
> I thought we opened all file descriptors with CLOEXEC?  If not, that's a
> bug, since we'd be leaking file descriptors to programs we start with
> `call-process', for instance.

What about stadin/stdout/stderr etc.?

> >   . does the restarted Emacs belong to the same process group? should
> >     it?
> 
> I think so, and I guess so?

Is that guaranteed? should we make sure it's so?  Or is it
unimportant?

> >   . on MS-Windows, if any of the argv[] command-line arguments have
> >     embedded whitespace, the restarted Emacs will not get the same
> >     elements in its argv[] array, because the Windows API for starting
> >     processes accepts the command-line arguments as a single string
> 
> Sounds like we should just document that this doesn't work on Windows,
> then.

It works now, at least in the GUI sessions.

Some other questions related to this:

  . AFAIU, the execvp'ed process inherits the environment of the
    calling process, so any changes to the environment will be
    propagated to the child, right?  Do we want that?

  . What about the working directory?  If the original Emacs was
    invoked with --chdir, the restart happens in another directory;
    moreover, relative program name in argv[0] and relative directory
    name in --chdir may not work.  Is that a problem?

  . What should happen to client frames when Emacs is restarted?  What
    does happen with the current implementation, .e.g if some of the
    client frames are on other displays?

A lot of this stuff has to do with the semantics of "restarting"
Emacs: what exactly does that mean, and what should users expect/not
expect when they restart Emacs?