JEP 102 Process Updates revised API draft

David M. Lloyd david.lloyd at redhat.com
Tue Feb 10 13:17:08 UTC 2015


On 02/09/2015 07:52 PM, Roger Riggs wrote:
> On 2/9/15 6:44 PM, David M. Lloyd wrote:
>> 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.

Understood, but I'm thinking that such a statement should be added; 
something along the lines of "Forcible process destruction is defined as 
the immediate termination of a process, whereas regular destruction 
allows a process to shut down cleanly."  This gives a clear criterion as 
to what it means when isDestroyForcible returns true, since each of 
these behaviors (at least on Unix) are readily identified with SIGKILL 
and SIGTERM.

Upon rereading the API I see that isDestroyForcible() actually reflects 
the behavior of destroy(), which is opposite of my original reading of 
it, and that clarifies things a bit.  But there is still no way in the 
API to know if forcible process termination is supported; can it be 
assumed that it is supported on all platforms?

> The descriptions are copied from Process, which previously did not offer
> an explanation.

-- 
- DML



More information about the core-libs-dev mailing list