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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> >   . 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?

If you exit from the new process, then you'll get the exit code from
that next call to `kill-emacs'?

>> 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.?

Those are inherited, I think.  (Which is good.)

>> >   . 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?

I think that whatever the OS does here by default is what's correct, so
it's not something we need to worry about.

>> Sounds like we should just document that this doesn't work on Windows,
>> then.
>
> It works now, at least in the GUI sessions.

Great!

> 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?

I'm not quite sure.  We could save envp and call execve instead with
that saved envp (I think?), but I think using the environment is what we
want here.  Probably?  But perhaps that should be an option...

>   . 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?

Ah, yes it is.  --chdir and relative names stops this from working, so
that needs fixing, I think. 

>   . 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?

I expect those to disappear.  We're restarting Emacs, after all.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no