On 20 March 2014 03:45, Eli Zaretskii wrote: > > Date: Wed, 19 Mar 2014 21:14:22 +0000 > > From: Reuben Thomas > > Cc: Stefan Monnier , 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