RFR 9: 8064932: test java/lang/ProcessBuilder/Basic.java: waitFor didn't take long enough
roger.riggs at oracle.com
Tue Nov 18 22:28:37 UTC 2014
Done, added the test and immediate return after the wait.
On Windows, the Thread.interrupted check needs to be done first to be
consistent with Unix.
Refactored a bit to remove a local variable and extra arithmetic
computing the remainingNanos.
On 11/18/2014 4:58 PM, Martin Buchholz wrote:
> I think we're all 3 in agreement on the general direction, even if we
> disagree on the details.
> Once we properly round to millis, it is no longer necessary to use
> Math.max - just
> wait(NANOSECONDS.toMillis(rem + 999_999L));
> As in my proposed change, I would like every call to wait immediately
> followed by a check
> if (hasExited)
> return true;
> to avoid the extra call to nanoTime.
> On Tue, Nov 18, 2014 at 12:09 PM, roger riggs <roger.riggs at oracle.com> wrote:
>> Work on Object.wait is an issue to be taken up separately.
>> I agree that the timeout values should not be truncated to milliseconds,
>> causing an additional cycle through the while loop and waiting.
>> The Process.waitFor methods are expected to wait for the specified time to
>> The webrev has been updated for both Windows and Unix to use a ceiling
>> on milliseconds and ensure that at least the requested time has elapsed.
>> Please review:
>> Thanks, Roger
>> On 11/18/2014 11:08 AM, Martin Buchholz wrote:
>>> On Mon, Nov 17, 2014 at 8:54 PM, David Holmes <david.holmes at oracle.com>
>>>> On 18/11/2014 2:43 PM, Martin Buchholz wrote:
>>>>> Proposed sibling change
>>>>> - don't unconditionally call nanoTime when the wait ends
>>>>> - use the millis/nanos form of Object.wait in case sub-millisecond
>>>>> waits are ever supported.
>>>> I don't really see the point of adding the extra math, plus an extra call
>>>> (the two arg wait will call the one arg version) for no actual gain.
>>> The idea was to code to the Object.wait API, not its current
>>> implementation with only millisecond resolution.
>>> Even if we code to the current implementation, we should round UP not
>>> to avoid the problem of needing to call wait twice in case of early
>>> That would also be progress.
>>>> If you want to add a fast exit path that's fine but the rest seems
>>>> superfluous to me.
More information about the core-libs-dev