RFR: 8263729: [test] Extend time to wait before destroying child in ProcssBuilder Basic test
Ioi Lam
iklam at openjdk.java.net
Wed Mar 17 16:38:48 UTC 2021
On Wed, 17 Mar 2021 15:18:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:
>> test/jdk/java/lang/ProcessBuilder/Basic.java line 2183:
>>
>>> 2181: latch.await();
>>> 2182: Thread.sleep(100L); // Wait for child initialization to settle
>>> 2183:
>>
>> Hi Roger,
>> Shouldn't the code that follows this sleep already be enough to wait for child thread to get a lock on the stream?
>>
>> Thread.sleep(100L); // Wait for child initialization to settle
>>
>> if (s instanceof BufferedInputStream) {
>> // Wait until after the s.read occurs in "thread" by
>> // checking when the input stream monitor is acquired
>> // (BufferedInputStream.read is synchronized)
>> while (!isLocked(s, 10)) {
>> Thread.sleep(100);
>> }
>> }
>>
>>
>> From 1st glance I would conclude that the 1st sleep is unnecessary. Is there a platform where Input/Error stream is not a BufferedInputStream? Or is it calling Process.destory() immediately after the child thread enters BufferedInputStream.read synchronized method perhaps too early to trigger appropriate exception in the child thread? In that case the additional sleep should be added after the while(!isLocked... loop.
>
> That loop is checking that the Thread (in the parent) reading from the child is in the correct state (blocked). On Windows, it is a BufferedInputStream.
>
> But it does not indicate anything about the state of the child process.
> From the scant information from previous failures, it appears that the the creation of some thread (not a java thread) in the child has failed.
> The additional time is to avoid destroying the child while it is still initializing.
The failures happened in tiers 6 and 8. The system may be overloaded so even 100ms may not be enough for the child process to start sleeping. From the error log, the child process tried to spawn a thread (probably one of those usually started during VM bootstrap) at around 118ms
[0.118s][warning][os,thread] Failed to start thread - _beginthreadex failed (EACCES) for attributes: stacksize: default, flags:
The test runs 4 times. Each time it checks only STDOUT or STDERR, but not both. So I think we can use the other stream to signal to the main process that the child process is ready. That would be more reliable than an arbitrary wait time.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3049
More information about the core-libs-dev
mailing list