Hi Peter,
On 3/25/14 2:50 AM, Peter Levart wrote:
On 03/24/2014 10:11 PM, roger riggs wrote:
Hi,
I'm starting to work on JEP 102, Process API Updates for JDK 9.
The use cases identified include test execution and build systems such
as Jtreg and Hudson/Jenkins. And there is a use-case for using Java
to monitor the health of a more complex system where the processes
are not spawned by the same manager.
The current API of Process itself is pretty complete with the
addition of a getPid
method to enable identification of subprocesses spawned by the
application
and allow external identification. It will not be possible to
intercept the input,
output and error streams of an arbitrary process.
From the scope of the JEP, a fairly simple API seems sufficient.
- Enumerate the direct children
What about self? An application might want to communicate it's own PID
to some other process (write it into a file, for example). Other
Process API methods are not sensible for "self" process so this might
as well be just simple static getSelfPid() method.
yes, I assume getPid() for the current process and Process.getPid().
- The rest of the functions are similar to Process
- to terminate a process, forcibly and normally
- to destroy a process and all of its children recursively
- to check if one is alive
- to waitFor for termination and retrieve the exit status
Are there use cases for which this is insufficient? Please comment.
It would be nice if this new API interoperated with old Process API in
a way that using both interchangeably for the same child process would
be possible. For example: spawning a child with old Process API and
enumerating/waiting/checking it with new API in some thread while
waiting for termination using old API in another thread...
Why make it more complex. What's the value?
The current Process object is a capability, no one can control it unless
they have
the instance. Security is based on the permission to execute the
binary. SM.checkExec().
Having an interface with the common function may be useful but the
usefulness
of the polymorphism needs to be validated.
I wonder if an approach to just add getPid() (and maybe some other
method) to old Process class together with some static methods to
enumerate child processes would be possible?
That makes sense to extend the current API but is not sufficient for
processes
not spawned by Process. The enumeration of the children would not be
Processes,
a different type of process handle is needed.
It would just require the API specification to strengthen it's
guarantees on some methods: for example destroyForcibly() would
guarantee forcible termination. It might require an additional method
like destroyNicely() or terminateNicely() which would guarantee a kind
of termination where victim process could clean-up. The specification
already allows getInputStream()/getOutputStream()/getErrorStream() to
return special "null streams" when spawned process IO is redirected
to/from file. The enumeration methods could simply return Process
object which would:
- be same instances of Process objects created with ProcessBuilder API
for processes spawned by the Process API. This would require an
internal registry of live Process objects. We already have reaper
threads which could be used to clean-up this registry on process
termination.
- be new Process objects for child processes spawned in some other way
(or by children) and which would return special "null streams" from
their getInputStream()/getOutputStream()/getErrorStream() methods.
These Process objects could be instantiated lazily on first request
and then registered in the same internal registry. They might still
require reaper threads to enable waiting on them from multiple Java
threads and cleaning-up registry, but they could probably be created
lazily.
The worst thing is to have an entirely separate API that does not
interoperate with old API. I think the old API is not so bad. It just
lacks some features and it's implementation could be revamped a bit.
I'm quite leery of just glombing on new functions to Process especially
those forcing
the Process API semantics to be weakened and diluted; it is likely to
make the implementation
even more complex and hard to maintain. I think there are distinct
functions for
managing non-spawned processes.
There are also security issues to consider, an application that might
have permission
to launch and control specific other programs should not be able
(without other permissions)
to control those processes children or other processes.
Roger
What do you think?
Regards, Peter
Thanks, Roger
