Process API Updates (JEP 102) (original) (raw)
Peter Levart peter.levart at gmail.com
Tue Mar 25 09:50:41 UTC 2014
- Previous message: Process API Updates (JEP 102)
- Next message: Process API Updates (JEP 102)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- 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...
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?
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.
What do you think?
Regards, Peter
Thanks, Roger
- Previous message: Process API Updates (JEP 102)
- Next message: Process API Updates (JEP 102)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]