JEP 102 Process Updates revised API draft

Roger Riggs Roger.Riggs at Oracle.com
Tue Feb 10 01:52:06 UTC 2015


Hi David,

On 2/9/15 6:44 PM, David M. Lloyd wrote:
> On 02/09/2015 05:25 PM, Roger Riggs wrote:
>> Hi,
>>
>> After a protracted absence from working on JEP 102, the updated API 
>> draft
>> provides access to process hierarchies and individual process 
>> information;
>> as permitted by the OS. The relationship between Process and 
>> ProcessHandle
>> is clarified and the security model validated.
>>
>> Both Processes and ProcessHandles can be monitored using 
>> CompletableFuture
>> for termination and to trigger additional actions on Process exit.
>> Information about processes includes the total cputime, starttime, user,
>> executable, and arguments.
>>
>> Please review and comment:
>>     http://cr.openjdk.java.net/~rriggs/ph-apidraft/
>
> Great, I'm glad to see this come to fruition.  I have a couple minor 
> questions though.
>
> ProcessHandle.Info provides a startTime and totalTime.  But it seems 
> odd and inconsistent that startTime is an Instant, yet totalTime is a 
> raw long as opposed to the arguably more consistent Duration.  Is 
> there a reason you went with a raw long for this property?
I considered a Duration, but Duration is a relative time; it make senses 
to add it to an absolute
time to come up with another absolute time.
But it didn't seem completely correct since CPU time is not accumulated 
continuously.
For ease in formatting, Duration.ofNanos(nn) can be used.
I'm open to suggestions.
>
> Also, as a general comment, there isn't really a good explanation as 
> to what the difference is between a normal destroy and a forcible 
> destroy.  Given that you've added an isDestroyForcible() method, I 
> think it might be a good idea to explain what it means when this 
> method returns true.  There must be some criteria in the 
> implementation to return true here, so at the least, that criteria 
> should be explained.  Also the destroy() method now has the odd 
> characteristic that its implementation *may* forcibly destroy a 
> process, but you can't really determine that from the API at all.
 From an implementation perspective, for Unix it is the distinction 
between SIGTERM and SIGKILL;
one is allowed/expected to be caught and handled by the application for 
a clean shutdown,
the other is not interceptable.
But the OS variations and caveats make it hard to write anything more 
than an informative statement.
The descriptions are copied from Process, which previously did not offer 
an explanation.

Thanks, Roger






More information about the core-libs-dev mailing list