1010
1111//! Job management on Windows for bootstrapping
1212//!
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
1414//! Ctrl-C or abnormal termination to actually terminate the entire tree of
1515//! process in play, not just the one at the top. This currently works "by
1616//! default" on Unix platforms because Ctrl-C actually sends a signal to the
@@ -162,11 +162,11 @@ pub unsafe fn setup(build: &mut Build) {
162162 return
163163 }
164164
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)
166166 // 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.
168168 //
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
170170 // intentionally leak the job object handle. When our process exits
171171 // (normally or abnormally) it will close the handle implicitly, causing all
172172 // processes in the job to be cleaned up.
@@ -184,7 +184,7 @@ pub unsafe fn setup(build: &mut Build) {
184184
185185 // If this failed, well at least we tried! An example of DuplicateHandle
186186 // 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
188188 // `mingw-w64-x86_64-python2`. Not sure why it failed, but the "failure
189189 // mode" here is that we only clean everything up when the build system
190190 // dies, not when the python parent does, so not too bad.
0 commit comments