aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/java_tools/junitrunner/java/com/google/testing/junit/runner/junit4
diff options
context:
space:
mode:
authorGravatar Philipp Wollermann <philwo@google.com>2017-03-15 15:34:11 +0000
committerGravatar Yun Peng <pcloudy@google.com>2017-03-16 08:34:56 +0000
commite4d977ffafa37eefe88b9228ab28b36b0f87d5ee (patch)
tree81c7ab87ff2a261bfc0b24f9dc9eec660da2fac6 /src/java_tools/junitrunner/java/com/google/testing/junit/runner/junit4
parent42ee2a1cb88b695e59ef8c920aa770822633c059 (diff)
windows: Don't try to breakaway from an existing Job in batch mode.
Reasoning: It never worked anyway, because Bazel didn't set the JOB_OBJECT_LIMIT_BREAKAWAY_OK limit on its job. This is why running Bazel in batch mode inside a shell integration test on Windows caused a "CreateProcess() failed: access denied" error. By no longer using CREATE_BREAKAWAY_FROM_JOB, this will instead cause us to use nested jobs, which is exactly the right thing to do: - If our parent dies, we and our children still get reliably killed. - But if *only* we die, then just our children will be reliably killed. If we're on an older Windows that doesn't support nested jobs and are running inside an existing job, we should assume that our parent handles process management - for example like Bazel, which runs all spawned processes in their own job. Also remove the CREATE_NEW_PROCESS_GROUP flag in Bazel's batch mode, because I can't see how this makes sense for a non-daemon process. -- PiperOrigin-RevId: 150194586 MOS_MIGRATED_REVID=150194586
Diffstat (limited to 'src/java_tools/junitrunner/java/com/google/testing/junit/runner/junit4')
0 files changed, 0 insertions, 0 deletions