Process API Updates (JEP 102)

[Roger Riggs]

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