On Tue, 24 Aug 2021 16:16:45 GMT, Ioi Lam <[email protected]> wrote:
>> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified
>> unexpected messages from a child Java VM
>> as the cause of the test failure. Attempts to control the output of the
>> child VM have failed, the VM is unrepentant .
>>
>> There is no functionality in the child except to wait long enough for the
>> test to finish and the child is destroyed.
>> The fix is to switch from using a Java child to using a native child; a new
>> executable `sleepmillis`.
>
> test/jdk/java/lang/ProcessBuilder/Basic.java line 2635:
>
>> 2633: List<String> childArgs = null;
>> 2634: Path sleepExe = TEST_NATIVEPATH.resolve("sleepmillis");
>> 2635: if (sleepExe.toFile().canExecute()) {
>
> Why is the fallback necessary? Other test cases such as
> test/jdk/tools/launcher/JliLaunchTest.java do not have such a fallback.
>
> Also, I noticed that JliLaunchTest does something like this:
>
>
> Path launcher = Paths.get(System.getProperty("test.nativepath"),
> "JliLaunchTest" + (Platform.isWindows() ? ".exe" : ""));
>
>
> but test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
> doesn't add ".exe", so it may not be necessary.
See above, the java Child is more portable and lower maintenance.
Windows looks for xxx.exe if xxx is not found.
> test/jdk/java/lang/ProcessBuilder/exeSleepMillis.c line 45:
>
>> 43: sleeptime.tv_nsec = (millis % 1000) * 1000 * 1000;
>> 44: int rc;
>> 45: while ((rc = nanosleep(&sleeptime, &sleeptime)) > 0) {
>
> is `nanosleep` a portable call? I couldn't find documentation for it with
> google search of `nanosleep site:docs.microsoft.com`.
Sadly, true.
Falling back to the portable 'sleep(seconds)' is necessary; but the timing will
be less precise.
C++ supports a higher resolution 'sleep_for' but the JDK native test build does
not support building
main programs using C++ and its not worth the complications added.
-------------
PR: https://git.openjdk.java.net/jdk/pull/5239
