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

[Eli Zaretskii]

> Resent-From: Eli Zaretskii <eliz@gnu.org>
> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
> Resent-CC: bug-gnu-emacs@gnu.org
> Resent-Sender: help-debbugs@gnu.org
> Date: Sun, 17 Apr 2022 15:34:55 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: rgm@gnu.org, 17036@debbugs.gnu.org, schwab@linux-m68k.org, rrt@sc3d.org
> 
> > 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:08:49 +0200
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > > As implemented, it won't work reliably on MS-Windows, because execvp
> > > there doesn't do what you think it should.  I think we should use
> > > sys_spawnve instead.
> > 
> > Ah, I grepped for execvp to see whether we already used it, but didn't
> > notice that the hits were from Gnulib.
> > 
> > I'm not familiar with sys_spawnve -- can you do the adjustments?
> 
> I don't think I will have the time.  It isn't a simple job, because
> just calling sys_spawnve will not do -- that function currently
> supports only Emacs sub-processes.
> 
> FTR, I will document below the potential issues with the current
> implementation of kill-emacs/restart-emacs:
> 
>   . when kill-emacs is called with RESTART non-nil, the value of ARG
>     is ignored; this should at least be documented;
>   . 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;
>   . 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?
>   . does the restarted Emacs belong to the same process group? should
>     it?
>   . 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

And one more:

  . my reading of the code in 'main' is that the argv[] array is
    sorted as it is processed, so the restarted Emacs will get the
    arguments in a different order (not that it should matter too
    much, I think, but still: it isn't exactly the same invocation)