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.ri...@oracle.com
<mailto:roger.ri...@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
