RFR 9: 8086208 : java/lang/ProcessHandle/OnExitTest.java: IllegalThreadStateException: process hasn't exited

[David Holmes]

On 16/06/2015 7:21 AM, Roger Riggs wrote:
> Hi Martin,
>
> Since the function is called from the FJ pool; what would result from
> propagating the interrupt?
> The FJPool reports the interrupted to the task but otherwise just clears
> it.
> It does not affect the completion status.
>
> Since it is known that the process has terminated and is only waiting
> for the
> Thread in ProcessImpl to post the status; it cannot/should not proceed
> until the
> exitValue is valid.
>
> The webrev has been updated to propagate the interrupted status but it will
> likely be ignored/discarded.

The key thing with handling interruption is to not assume you know what 
an interruption might mean for higher level code. So if you must 
complete regardless of interruption then either propagate the 
InterruptedException or re-assert the interrupt state. So what you have 
is idiomatically good code, even if in this case the higher level code 
couldn't care less. :)

Style nit: AFAIK we never explicitly import top-level java.lang classes 
like InterruptedException.

Cheers,
David

> Roger
>
>
>
> On 6/15/2015 4:46 PM, Martin Buchholz wrote:
>> if you do get interrupted, the interrupt is swallowed, which seems wrong.
>>
>> Other waiting methods have "uninterruptible" variants, that restore
>> the interrupt status, like Semaphore.acquireUninterruptibly.  Should
>> there be a Process.waitForUninterruptibly?
>>
>> On Mon, Jun 15, 2015 at 1:37 PM, Roger Riggs <Roger.Riggs at oracle.com
>> <mailto:Roger.Riggs at oracle.com>> wrote:
>>
>>     Please review a fix for a (Unix) race condition for the exit
>>     status of Process.onExit.
>>     And some source cleanup of OnExitTest.
>>
>>     Webrev:
>>     http://cr.openjdk.java.net/~rriggs/webrev-race-8086208/
>>     <http://cr.openjdk.java.net/%7Erriggs/webrev-race-8086208/>
>>
>>     Issue:
>>     https://bugs.openjdk.java.net/browse/JDK-8086208
>>
>>     Roger
>>
>>
>