Hi Ron,
I have not looked at that idea closely but I would be concerned
about the robustness of the 2nd, execve'd Java runtime. Since it would
not be
a brand new process, there might be leftover state from the previous
execution that would break the usual assumptions of a newly started Java
Runtime.
Anything from signal handler state to open file descriptors to the specific
memory mapping and there may be others.
Roger
On 8/26/2014 7:25 AM, Ron Pressler wrote:
I might be a little late to this party, but recently I've had a (rather
frustrating) need for the ability to execve a process rather than fork-exec
it. I understand that the ability to exec (replace the current process's
image) is also available on Windows. This operation (on ProcessBuilder?),
which never returns, would have the same semantics as
System.exit(pb.start().waitFor()), only it would replace the current JVM
process (i.e. maintain the same pid/handle) with the command.
This is required when a JVM process is used to set up and launch another,
JVM or other, process, but we'd want the user running the program to be
oblivious to the setup process (because, say, they want to monitor the
running program with some OS tool).
Ron
