OpenE2K/rust
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

bootstrap: Be resilient to job object failures

Browse Source 
The build bots already use job objects, and they don't support nested job
objects, and we shouldn't entirely bail out in this case anyway!
This commit is contained in:
Alex Crichton 2016-02-11 20:46:47 -08:00
parent a1c13d03a5
commit 07638b95ce
1 changed files with 13 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
src/bootstrap/build/job.rs
View File

@ -64,9 +64,20 @@ pub unsafe fn setup() {
mem::size_of_val(&info) as DWORD);
assert!(r != 0, "{}", io::Error::last_os_error());
// Assign our process to this job object
// Assign our process to this job object. Note that if this fails, one very
// likely reason is that we are ourselves already in a job object! This can
// happen on the build bots that we've got for Windows, or if just anyone
// else is instrumenting the build. In this case we just bail out
// immediately and assume that they take care of it.
//
// Also note that nested jobs (why this might fail) are supported in recent
// versions of Windows, but the version of Windows that our bots are running
// at least don't support nested job objects.
let r = AssignProcessToJobObject(job, GetCurrentProcess());
assert!(r != 0, "{}", io::Error::last_os_error());
if r == 0 {
CloseHandle(job);
return
}
// If we've got a parent process (e.g. the python script that called us)
// then move ownership of this job object up to them. That way if the python