On Wed, 17 Mar 2021 14:52:36 GMT, Peter Levart <plev...@openjdk.org> wrote:
>> Intermittent failures on Windows in a test of destroying the child warrant
>> extending the time the parent waits after starting the child before
>> destroying the child.
>
> 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.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3049
