RFR: JDK-8154326: bash >(...) construct causes race conditions

[Tim Bell]

Erik:

> Unfortunately, this did not work well. The problem with the added "&& 
> wait" materializes if the caller of ExecuteWithLog tries to pipe the 
> output of that command, which we do frequently on Windows. To solve 
> it, another level of parentheses are needed. Unfortunately this adds 
> another shell process for each call, which makes the Windows build 
> slightly slower again. I don't see any other solution however.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8154326/webrev.02/

OK, looks good to me.

/Tim

> On 2016-04-19 14:32, Erik Joelsson wrote:
>> Hello,
>>
>> After switching to the new hotspot build, we have seen some sporadic 
>> build errors related to the generation of dtrace JvmOffsets.h file on 
>> Solaris. The errors look like a compile target that depends on the 
>> header file fails because the header file is either empty or 
>> incomplete. I have managed to reproduce this by running this 
>> particular part of the build in a loop within 5 minutes.
>>
>> The header file generation uses the rather new ExecuteWithLog macro, 
>> which uses the also rather new ">(tee logfile)" construct to save 
>> output to a log file while still echoing both stderr and stdout 
>> separately to the console. It seems however, that when using this 
>> construct, bash spawns background processes which may not be done 
>> when the main process is done.
>>
>> I have noted a similar effect when switching to this construct for 
>> the main makefile build.log. The last line of make output would be 
>> echoed to the console after my prompt returned.
>>
>> To solve this, I added "&& wait" in each location where the >(...) 
>> trick is used. I have then rerun the loop over night and could no 
>> longer reproduce the problem. I believe this to be the proper solution.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154326
>> Webrev: http://cr.openjdk.java.net/~erikj/8154326/webrev.01/
>>
>> /Erik
>