10
10
11
11
//! Job management on Windows for bootstrapping
12
12
//!
13
- //! Most of the time when you're running a build system (e.g. make) you expect
13
+ //! Most of the time when you're running a build system (e.g., make) you expect
14
14
//! Ctrl-C or abnormal termination to actually terminate the entire tree of
15
15
//! process in play, not just the one at the top. This currently works "by
16
16
//! default" on Unix platforms because Ctrl-C actually sends a signal to the
@@ -162,11 +162,11 @@ pub unsafe fn setup(build: &mut Build) {
162
162
return
163
163
}
164
164
165
- // If we've got a parent process (e.g. the python script that called us)
165
+ // If we've got a parent process (e.g., the python script that called us)
166
166
// then move ownership of this job object up to them. That way if the python
167
- // script is killed (e.g. via ctrl-c) then we'll all be torn down.
167
+ // script is killed (e.g., via ctrl-c) then we'll all be torn down.
168
168
//
169
- // If we don't have a parent (e.g. this was run directly) then we
169
+ // If we don't have a parent (e.g., this was run directly) then we
170
170
// intentionally leak the job object handle. When our process exits
171
171
// (normally or abnormally) it will close the handle implicitly, causing all
172
172
// processes in the job to be cleaned up.
@@ -184,7 +184,7 @@ pub unsafe fn setup(build: &mut Build) {
184
184
185
185
// If this failed, well at least we tried! An example of DuplicateHandle
186
186
// failing in the past has been when the wrong python2 package spawned this
187
- // build system (e.g. the `python2` package in MSYS instead of
187
+ // build system (e.g., the `python2` package in MSYS instead of
188
188
// `mingw-w64-x86_64-python2`. Not sure why it failed, but the "failure
189
189
// mode" here is that we only clean everything up when the build system
190
190
// dies, not when the python parent does, so not too bad.
0 commit comments