cargo/tests/testsuite/jobserver.rs

382 lines
9.3 KiB
Rust
Raw Normal View History

2019-11-25 02:42:45 +00:00
//! Tests for the jobserver protocol.
use cargo_util::is_ci;
use std::env;
Add a GNU make jobserver implementation to Cargo This commit adds a GNU make jobserver implementation to Cargo, both as a client of existing jobservers and also a creator of new jobservers. The jobserver is actually just an IPC semaphore which manifests itself as a pipe with N bytes of tokens on Unix and a literal IPC semaphore on Windows. The rough protocol is then if you want to run a job you read acquire the semaphore (read a byte on Unix or wait on the semaphore on Windows) and then you release it when you're done. All the hairy details of the jobserver implementation are housed in the `jobserver` crate on crates.io instead of Cargo. This should hopefully make it much easier for the compiler to also share a jobserver implementation eventually. The main tricky bit here is that on Unix and Windows acquiring a jobserver token will block the calling thread. We need to either way for a running job to exit or to acquire a new token when we want to spawn a new job. To handle this the current implementation spawns a helper thread that does the blocking and sends a message back to Cargo when it receives a token. It's a little trickier with shutting down this thread gracefully as well but more details can be found in the `jobserver` crate. Unfortunately crates are unlikely to see an immediate benefit of this once implemented. Most crates are run with a manual `make -jN` and this overrides the jobserver in the environment, creating a new jobserver in the sub-make. If the `-jN` argument is removed, however, then `make` will share Cargo's jobserver and properly limit parallelism. Closes #1744
2017-05-30 04:09:53 +00:00
use std::net::TcpListener;
use std::process::Command;
use std::thread;
Add a GNU make jobserver implementation to Cargo This commit adds a GNU make jobserver implementation to Cargo, both as a client of existing jobservers and also a creator of new jobservers. The jobserver is actually just an IPC semaphore which manifests itself as a pipe with N bytes of tokens on Unix and a literal IPC semaphore on Windows. The rough protocol is then if you want to run a job you read acquire the semaphore (read a byte on Unix or wait on the semaphore on Windows) and then you release it when you're done. All the hairy details of the jobserver implementation are housed in the `jobserver` crate on crates.io instead of Cargo. This should hopefully make it much easier for the compiler to also share a jobserver implementation eventually. The main tricky bit here is that on Unix and Windows acquiring a jobserver token will block the calling thread. We need to either way for a running job to exit or to acquire a new token when we want to spawn a new job. To handle this the current implementation spawns a helper thread that does the blocking and sends a message back to Cargo when it receives a token. It's a little trickier with shutting down this thread gracefully as well but more details can be found in the `jobserver` crate. Unfortunately crates are unlikely to see an immediate benefit of this once implemented. Most crates are run with a manual `make -jN` and this overrides the jobserver in the environment, creating a new jobserver in the sub-make. If the `-jN` argument is removed, however, then `make` will share Cargo's jobserver and properly limit parallelism. Closes #1744
2017-05-30 04:09:53 +00:00
use cargo_test_support::basic_bin_manifest;
use cargo_test_support::cargo_exe;
use cargo_test_support::install::assert_has_installed_exe;
use cargo_test_support::install::cargo_home;
use cargo_test_support::project;
use cargo_test_support::rustc_host;
Add a GNU make jobserver implementation to Cargo This commit adds a GNU make jobserver implementation to Cargo, both as a client of existing jobservers and also a creator of new jobservers. The jobserver is actually just an IPC semaphore which manifests itself as a pipe with N bytes of tokens on Unix and a literal IPC semaphore on Windows. The rough protocol is then if you want to run a job you read acquire the semaphore (read a byte on Unix or wait on the semaphore on Windows) and then you release it when you're done. All the hairy details of the jobserver implementation are housed in the `jobserver` crate on crates.io instead of Cargo. This should hopefully make it much easier for the compiler to also share a jobserver implementation eventually. The main tricky bit here is that on Unix and Windows acquiring a jobserver token will block the calling thread. We need to either way for a running job to exit or to acquire a new token when we want to spawn a new job. To handle this the current implementation spawns a helper thread that does the blocking and sends a message back to Cargo when it receives a token. It's a little trickier with shutting down this thread gracefully as well but more details can be found in the `jobserver` crate. Unfortunately crates are unlikely to see an immediate benefit of this once implemented. Most crates are run with a manual `make -jN` and this overrides the jobserver in the environment, creating a new jobserver in the sub-make. If the `-jN` argument is removed, however, then `make` will share Cargo's jobserver and properly limit parallelism. Closes #1744
2017-05-30 04:09:53 +00:00
const EXE_CONTENT: &str = r#"
use std::env;
fn main() {
let var = env::var("CARGO_MAKEFLAGS").expect("no jobserver from env");
let arg = var.split(' ')
.find(|p| p.starts_with("--jobserver"))
.unwrap();
let val = &arg[arg.find('=').unwrap() + 1..];
validate(val);
}
#[cfg(unix)]
fn validate(s: &str) {
use std::fs::{self, File};
use std::io::*;
use std::os::unix::prelude::*;
if let Some((r, w)) = s.split_once(',') {
// `--jobserver-auth=R,W`
unsafe {
let mut read = File::from_raw_fd(r.parse().unwrap());
let mut write = File::from_raw_fd(w.parse().unwrap());
let mut buf = [0];
assert_eq!(read.read(&mut buf).unwrap(), 1);
assert_eq!(write.write(&buf).unwrap(), 1);
}
} else {
// `--jobserver-auth=fifo:PATH` is the default since GNU Make 4.4
let (_, path) = s.split_once(':').expect("fifo:PATH");
assert!(fs::metadata(path).unwrap().file_type().is_fifo());
}
}
#[cfg(windows)]
fn validate(_: &str) {
// a little too complicated for a test...
}
"#;
fn make_exe() -> &'static str {
if cfg!(windows) {
"mingw32-make"
} else {
"make"
}
}
#[cargo_test]
Add a GNU make jobserver implementation to Cargo This commit adds a GNU make jobserver implementation to Cargo, both as a client of existing jobservers and also a creator of new jobservers. The jobserver is actually just an IPC semaphore which manifests itself as a pipe with N bytes of tokens on Unix and a literal IPC semaphore on Windows. The rough protocol is then if you want to run a job you read acquire the semaphore (read a byte on Unix or wait on the semaphore on Windows) and then you release it when you're done. All the hairy details of the jobserver implementation are housed in the `jobserver` crate on crates.io instead of Cargo. This should hopefully make it much easier for the compiler to also share a jobserver implementation eventually. The main tricky bit here is that on Unix and Windows acquiring a jobserver token will block the calling thread. We need to either way for a running job to exit or to acquire a new token when we want to spawn a new job. To handle this the current implementation spawns a helper thread that does the blocking and sends a message back to Cargo when it receives a token. It's a little trickier with shutting down this thread gracefully as well but more details can be found in the `jobserver` crate. Unfortunately crates are unlikely to see an immediate benefit of this once implemented. Most crates are run with a manual `make -jN` and this overrides the jobserver in the environment, creating a new jobserver in the sub-make. If the `-jN` argument is removed, however, then `make` will share Cargo's jobserver and properly limit parallelism. Closes #1744
2017-05-30 04:09:53 +00:00
fn jobserver_exists() {
let p = project()
.file("build.rs", EXE_CONTENT)
2018-12-08 11:19:47 +00:00
.file("src/lib.rs", "")
.build();
Add a GNU make jobserver implementation to Cargo This commit adds a GNU make jobserver implementation to Cargo, both as a client of existing jobservers and also a creator of new jobservers. The jobserver is actually just an IPC semaphore which manifests itself as a pipe with N bytes of tokens on Unix and a literal IPC semaphore on Windows. The rough protocol is then if you want to run a job you read acquire the semaphore (read a byte on Unix or wait on the semaphore on Windows) and then you release it when you're done. All the hairy details of the jobserver implementation are housed in the `jobserver` crate on crates.io instead of Cargo. This should hopefully make it much easier for the compiler to also share a jobserver implementation eventually. The main tricky bit here is that on Unix and Windows acquiring a jobserver token will block the calling thread. We need to either way for a running job to exit or to acquire a new token when we want to spawn a new job. To handle this the current implementation spawns a helper thread that does the blocking and sends a message back to Cargo when it receives a token. It's a little trickier with shutting down this thread gracefully as well but more details can be found in the `jobserver` crate. Unfortunately crates are unlikely to see an immediate benefit of this once implemented. Most crates are run with a manual `make -jN` and this overrides the jobserver in the environment, creating a new jobserver in the sub-make. If the `-jN` argument is removed, however, then `make` will share Cargo's jobserver and properly limit parallelism. Closes #1744
2017-05-30 04:09:53 +00:00
// Explicitly use `-j2` to ensure that there's eventually going to be a
// token to read from `validate` above, since running the build script
// itself consumes a token.
p.cargo("check -j2").run();
Add a GNU make jobserver implementation to Cargo This commit adds a GNU make jobserver implementation to Cargo, both as a client of existing jobservers and also a creator of new jobservers. The jobserver is actually just an IPC semaphore which manifests itself as a pipe with N bytes of tokens on Unix and a literal IPC semaphore on Windows. The rough protocol is then if you want to run a job you read acquire the semaphore (read a byte on Unix or wait on the semaphore on Windows) and then you release it when you're done. All the hairy details of the jobserver implementation are housed in the `jobserver` crate on crates.io instead of Cargo. This should hopefully make it much easier for the compiler to also share a jobserver implementation eventually. The main tricky bit here is that on Unix and Windows acquiring a jobserver token will block the calling thread. We need to either way for a running job to exit or to acquire a new token when we want to spawn a new job. To handle this the current implementation spawns a helper thread that does the blocking and sends a message back to Cargo when it receives a token. It's a little trickier with shutting down this thread gracefully as well but more details can be found in the `jobserver` crate. Unfortunately crates are unlikely to see an immediate benefit of this once implemented. Most crates are run with a manual `make -jN` and this overrides the jobserver in the environment, creating a new jobserver in the sub-make. If the `-jN` argument is removed, however, then `make` will share Cargo's jobserver and properly limit parallelism. Closes #1744
2017-05-30 04:09:53 +00:00
}
#[cargo_test]
fn external_subcommand_inherits_jobserver() {
let make = make_exe();
if Command::new(make).arg("--version").output().is_err() {
return;
}
let name = "cargo-jobserver-check";
let p = project()
.file(
"Cargo.toml",
&format!(
r#"
[package]
name = "{name}"
version = "0.0.1"
"#
),
)
.file("src/main.rs", EXE_CONTENT)
.file(
"Makefile",
"\
all:
\t+$(CARGO) jobserver-check
",
)
.build();
p.cargo("install --path .").run();
assert_has_installed_exe(cargo_home(), name);
p.process(make).env("CARGO", cargo_exe()).arg("-j2").run();
}
#[cargo_test]
fn runner_inherits_jobserver() {
let make = make_exe();
if Command::new(make).arg("--version").output().is_err() {
return;
}
let runner = "runner";
project()
.at(runner)
.file("Cargo.toml", &basic_bin_manifest(runner))
.file(
"src/main.rs",
r#"
pub fn main() {
eprintln!("this is a runner");
let args: Vec<String> = std::env::args().collect();
let status = std::process::Command::new(&args[1]).status().unwrap();
assert!(status.success());
}
"#,
)
.build()
.cargo("install --path .")
.run();
// Add .cargo/bin to PATH
let mut path: Vec<_> = env::split_paths(&env::var_os("PATH").unwrap_or_default()).collect();
path.push(cargo_home().join("bin"));
let path = &env::join_paths(path).unwrap();
assert_has_installed_exe(cargo_home(), runner);
let host = rustc_host();
let config_value = &format!("target.{host}.runner = \"{runner}\"");
let name = "cargo-jobserver-check";
let p = project()
.file(
"Cargo.toml",
&format!(
r#"
[package]
name = "{name}"
version = "0.0.1"
"#
),
)
.file(
"src/lib.rs",
r#"
#[test]
fn test() {
_ = std::env::var("CARGO_MAKEFLAGS").expect("no jobserver from env");
}
"#,
)
.file("src/main.rs", EXE_CONTENT)
.file(
"Makefile",
&format!(
"\
run:
\t+$(CARGO) run
run-runner:
\t+$(CARGO) run --config '{config_value}'
test:
\t+$(CARGO) test --lib
test-runner:
\t+$(CARGO) test --lib --config '{config_value}'
",
),
)
.build();
// jobserver can be inherited from env
p.process(make)
.env("CARGO", cargo_exe())
.arg("run")
.arg("-j2")
.run();
p.process(make)
.env("PATH", path)
.env("CARGO", cargo_exe())
.arg("run-runner")
.arg("-j2")
.with_stderr_contains("[..]this is a runner[..]")
.run();
p.process(make)
.env("CARGO", cargo_exe())
.arg("test")
.arg("-j2")
.run();
p.process(make)
.env("PATH", path)
.env("CARGO", cargo_exe())
.arg("test-runner")
.arg("-j2")
.with_stderr_contains("[..]this is a runner[..]")
.run();
// but not from `-j` flag
p.cargo("run -j2")
.with_status(101)
.with_stderr_contains("[..]no jobserver from env[..]")
.run();
p.cargo("run -j2")
.env("PATH", path)
.arg("--config")
.arg(config_value)
.with_status(101)
.with_stderr_contains("[..]this is a runner[..]")
.with_stderr_contains("[..]no jobserver from env[..]")
.run();
p.cargo("test -j2")
.with_status(101)
.with_stdout_contains("[..]no jobserver from env[..]")
.run();
p.cargo("test -j2")
.env("PATH", path)
.arg("--config")
.arg(config_value)
.with_status(101)
.with_stderr_contains("[..]this is a runner[..]")
.with_stdout_contains("[..]no jobserver from env[..]")
.run();
}
#[cargo_test]
Add a GNU make jobserver implementation to Cargo This commit adds a GNU make jobserver implementation to Cargo, both as a client of existing jobservers and also a creator of new jobservers. The jobserver is actually just an IPC semaphore which manifests itself as a pipe with N bytes of tokens on Unix and a literal IPC semaphore on Windows. The rough protocol is then if you want to run a job you read acquire the semaphore (read a byte on Unix or wait on the semaphore on Windows) and then you release it when you're done. All the hairy details of the jobserver implementation are housed in the `jobserver` crate on crates.io instead of Cargo. This should hopefully make it much easier for the compiler to also share a jobserver implementation eventually. The main tricky bit here is that on Unix and Windows acquiring a jobserver token will block the calling thread. We need to either way for a running job to exit or to acquire a new token when we want to spawn a new job. To handle this the current implementation spawns a helper thread that does the blocking and sends a message back to Cargo when it receives a token. It's a little trickier with shutting down this thread gracefully as well but more details can be found in the `jobserver` crate. Unfortunately crates are unlikely to see an immediate benefit of this once implemented. Most crates are run with a manual `make -jN` and this overrides the jobserver in the environment, creating a new jobserver in the sub-make. If the `-jN` argument is removed, however, then `make` will share Cargo's jobserver and properly limit parallelism. Closes #1744
2017-05-30 04:09:53 +00:00
fn makes_jobserver_used() {
let make = make_exe();
if !is_ci() && Command::new(make).arg("--version").output().is_err() {
return;
}
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
d1 = { path = "d1" }
d2 = { path = "d2" }
d3 = { path = "d3" }
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "")
2018-03-14 15:17:44 +00:00
.file(
"d1/Cargo.toml",
r#"
2020-09-27 00:59:58 +00:00
[package]
name = "d1"
version = "0.0.1"
authors = []
build = "../dbuild.rs"
"#,
2018-12-08 11:19:47 +00:00
)
.file("d1/src/lib.rs", "")
2018-03-14 15:17:44 +00:00
.file(
"d2/Cargo.toml",
r#"
2020-09-27 00:59:58 +00:00
[package]
name = "d2"
version = "0.0.1"
authors = []
build = "../dbuild.rs"
"#,
2018-12-08 11:19:47 +00:00
)
.file("d2/src/lib.rs", "")
2018-03-14 15:17:44 +00:00
.file(
"d3/Cargo.toml",
r#"
2020-09-27 00:59:58 +00:00
[package]
name = "d3"
version = "0.0.1"
authors = []
build = "../dbuild.rs"
"#,
2018-12-08 11:19:47 +00:00
)
.file("d3/src/lib.rs", "")
2018-03-14 15:17:44 +00:00
.file(
"dbuild.rs",
r#"
2020-09-27 00:59:58 +00:00
use std::net::TcpStream;
use std::env;
use std::io::Read;
fn main() {
let addr = env::var("ADDR").unwrap();
let mut stream = TcpStream::connect(addr).unwrap();
let mut v = Vec::new();
stream.read_to_end(&mut v).unwrap();
}
"#,
2018-12-08 11:19:47 +00:00
)
.file(
2018-03-14 15:17:44 +00:00
"Makefile",
"\
Add a GNU make jobserver implementation to Cargo This commit adds a GNU make jobserver implementation to Cargo, both as a client of existing jobservers and also a creator of new jobservers. The jobserver is actually just an IPC semaphore which manifests itself as a pipe with N bytes of tokens on Unix and a literal IPC semaphore on Windows. The rough protocol is then if you want to run a job you read acquire the semaphore (read a byte on Unix or wait on the semaphore on Windows) and then you release it when you're done. All the hairy details of the jobserver implementation are housed in the `jobserver` crate on crates.io instead of Cargo. This should hopefully make it much easier for the compiler to also share a jobserver implementation eventually. The main tricky bit here is that on Unix and Windows acquiring a jobserver token will block the calling thread. We need to either way for a running job to exit or to acquire a new token when we want to spawn a new job. To handle this the current implementation spawns a helper thread that does the blocking and sends a message back to Cargo when it receives a token. It's a little trickier with shutting down this thread gracefully as well but more details can be found in the `jobserver` crate. Unfortunately crates are unlikely to see an immediate benefit of this once implemented. Most crates are run with a manual `make -jN` and this overrides the jobserver in the environment, creating a new jobserver in the sub-make. If the `-jN` argument is removed, however, then `make` will share Cargo's jobserver and properly limit parallelism. Closes #1744
2017-05-30 04:09:53 +00:00
all:
\t+$(CARGO) build
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.build();
Add a GNU make jobserver implementation to Cargo This commit adds a GNU make jobserver implementation to Cargo, both as a client of existing jobservers and also a creator of new jobservers. The jobserver is actually just an IPC semaphore which manifests itself as a pipe with N bytes of tokens on Unix and a literal IPC semaphore on Windows. The rough protocol is then if you want to run a job you read acquire the semaphore (read a byte on Unix or wait on the semaphore on Windows) and then you release it when you're done. All the hairy details of the jobserver implementation are housed in the `jobserver` crate on crates.io instead of Cargo. This should hopefully make it much easier for the compiler to also share a jobserver implementation eventually. The main tricky bit here is that on Unix and Windows acquiring a jobserver token will block the calling thread. We need to either way for a running job to exit or to acquire a new token when we want to spawn a new job. To handle this the current implementation spawns a helper thread that does the blocking and sends a message back to Cargo when it receives a token. It's a little trickier with shutting down this thread gracefully as well but more details can be found in the `jobserver` crate. Unfortunately crates are unlikely to see an immediate benefit of this once implemented. Most crates are run with a manual `make -jN` and this overrides the jobserver in the environment, creating a new jobserver in the sub-make. If the `-jN` argument is removed, however, then `make` will share Cargo's jobserver and properly limit parallelism. Closes #1744
2017-05-30 04:09:53 +00:00
let l = TcpListener::bind("127.0.0.1:0").unwrap();
let addr = l.local_addr().unwrap();
let child = thread::spawn(move || {
let a1 = l.accept().unwrap();
let a2 = l.accept().unwrap();
l.set_nonblocking(true).unwrap();
for _ in 0..1000 {
assert!(l.accept().is_err());
thread::yield_now();
}
drop(a1);
l.set_nonblocking(false).unwrap();
let a3 = l.accept().unwrap();
drop((a2, a3));
});
p.process(make)
2018-08-28 20:38:26 +00:00
.env("CARGO", cargo_exe())
.env("ADDR", addr.to_string())
.arg("-j2")
.run();
Add a GNU make jobserver implementation to Cargo This commit adds a GNU make jobserver implementation to Cargo, both as a client of existing jobservers and also a creator of new jobservers. The jobserver is actually just an IPC semaphore which manifests itself as a pipe with N bytes of tokens on Unix and a literal IPC semaphore on Windows. The rough protocol is then if you want to run a job you read acquire the semaphore (read a byte on Unix or wait on the semaphore on Windows) and then you release it when you're done. All the hairy details of the jobserver implementation are housed in the `jobserver` crate on crates.io instead of Cargo. This should hopefully make it much easier for the compiler to also share a jobserver implementation eventually. The main tricky bit here is that on Unix and Windows acquiring a jobserver token will block the calling thread. We need to either way for a running job to exit or to acquire a new token when we want to spawn a new job. To handle this the current implementation spawns a helper thread that does the blocking and sends a message back to Cargo when it receives a token. It's a little trickier with shutting down this thread gracefully as well but more details can be found in the `jobserver` crate. Unfortunately crates are unlikely to see an immediate benefit of this once implemented. Most crates are run with a manual `make -jN` and this overrides the jobserver in the environment, creating a new jobserver in the sub-make. If the `-jN` argument is removed, however, then `make` will share Cargo's jobserver and properly limit parallelism. Closes #1744
2017-05-30 04:09:53 +00:00
child.join().unwrap();
}
#[cargo_test]
Add a GNU make jobserver implementation to Cargo This commit adds a GNU make jobserver implementation to Cargo, both as a client of existing jobservers and also a creator of new jobservers. The jobserver is actually just an IPC semaphore which manifests itself as a pipe with N bytes of tokens on Unix and a literal IPC semaphore on Windows. The rough protocol is then if you want to run a job you read acquire the semaphore (read a byte on Unix or wait on the semaphore on Windows) and then you release it when you're done. All the hairy details of the jobserver implementation are housed in the `jobserver` crate on crates.io instead of Cargo. This should hopefully make it much easier for the compiler to also share a jobserver implementation eventually. The main tricky bit here is that on Unix and Windows acquiring a jobserver token will block the calling thread. We need to either way for a running job to exit or to acquire a new token when we want to spawn a new job. To handle this the current implementation spawns a helper thread that does the blocking and sends a message back to Cargo when it receives a token. It's a little trickier with shutting down this thread gracefully as well but more details can be found in the `jobserver` crate. Unfortunately crates are unlikely to see an immediate benefit of this once implemented. Most crates are run with a manual `make -jN` and this overrides the jobserver in the environment, creating a new jobserver in the sub-make. If the `-jN` argument is removed, however, then `make` will share Cargo's jobserver and properly limit parallelism. Closes #1744
2017-05-30 04:09:53 +00:00
fn jobserver_and_j() {
let make = make_exe();
if !is_ci() && Command::new(make).arg("--version").output().is_err() {
return;
}
let p = project()
.file("src/lib.rs", "")
2018-03-14 15:17:44 +00:00
.file(
"Makefile",
"\
Add a GNU make jobserver implementation to Cargo This commit adds a GNU make jobserver implementation to Cargo, both as a client of existing jobservers and also a creator of new jobservers. The jobserver is actually just an IPC semaphore which manifests itself as a pipe with N bytes of tokens on Unix and a literal IPC semaphore on Windows. The rough protocol is then if you want to run a job you read acquire the semaphore (read a byte on Unix or wait on the semaphore on Windows) and then you release it when you're done. All the hairy details of the jobserver implementation are housed in the `jobserver` crate on crates.io instead of Cargo. This should hopefully make it much easier for the compiler to also share a jobserver implementation eventually. The main tricky bit here is that on Unix and Windows acquiring a jobserver token will block the calling thread. We need to either way for a running job to exit or to acquire a new token when we want to spawn a new job. To handle this the current implementation spawns a helper thread that does the blocking and sends a message back to Cargo when it receives a token. It's a little trickier with shutting down this thread gracefully as well but more details can be found in the `jobserver` crate. Unfortunately crates are unlikely to see an immediate benefit of this once implemented. Most crates are run with a manual `make -jN` and this overrides the jobserver in the environment, creating a new jobserver in the sub-make. If the `-jN` argument is removed, however, then `make` will share Cargo's jobserver and properly limit parallelism. Closes #1744
2017-05-30 04:09:53 +00:00
all:
\t+$(CARGO) build -j2
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.build();
Add a GNU make jobserver implementation to Cargo This commit adds a GNU make jobserver implementation to Cargo, both as a client of existing jobservers and also a creator of new jobservers. The jobserver is actually just an IPC semaphore which manifests itself as a pipe with N bytes of tokens on Unix and a literal IPC semaphore on Windows. The rough protocol is then if you want to run a job you read acquire the semaphore (read a byte on Unix or wait on the semaphore on Windows) and then you release it when you're done. All the hairy details of the jobserver implementation are housed in the `jobserver` crate on crates.io instead of Cargo. This should hopefully make it much easier for the compiler to also share a jobserver implementation eventually. The main tricky bit here is that on Unix and Windows acquiring a jobserver token will block the calling thread. We need to either way for a running job to exit or to acquire a new token when we want to spawn a new job. To handle this the current implementation spawns a helper thread that does the blocking and sends a message back to Cargo when it receives a token. It's a little trickier with shutting down this thread gracefully as well but more details can be found in the `jobserver` crate. Unfortunately crates are unlikely to see an immediate benefit of this once implemented. Most crates are run with a manual `make -jN` and this overrides the jobserver in the environment, creating a new jobserver in the sub-make. If the `-jN` argument is removed, however, then `make` will share Cargo's jobserver and properly limit parallelism. Closes #1744
2017-05-30 04:09:53 +00:00
p.process(make)
2018-08-28 20:38:26 +00:00
.env("CARGO", cargo_exe())
.arg("-j2")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
Add a GNU make jobserver implementation to Cargo This commit adds a GNU make jobserver implementation to Cargo, both as a client of existing jobservers and also a creator of new jobservers. The jobserver is actually just an IPC semaphore which manifests itself as a pipe with N bytes of tokens on Unix and a literal IPC semaphore on Windows. The rough protocol is then if you want to run a job you read acquire the semaphore (read a byte on Unix or wait on the semaphore on Windows) and then you release it when you're done. All the hairy details of the jobserver implementation are housed in the `jobserver` crate on crates.io instead of Cargo. This should hopefully make it much easier for the compiler to also share a jobserver implementation eventually. The main tricky bit here is that on Unix and Windows acquiring a jobserver token will block the calling thread. We need to either way for a running job to exit or to acquire a new token when we want to spawn a new job. To handle this the current implementation spawns a helper thread that does the blocking and sends a message back to Cargo when it receives a token. It's a little trickier with shutting down this thread gracefully as well but more details can be found in the `jobserver` crate. Unfortunately crates are unlikely to see an immediate benefit of this once implemented. Most crates are run with a manual `make -jN` and this overrides the jobserver in the environment, creating a new jobserver in the sub-make. If the `-jN` argument is removed, however, then `make` will share Cargo's jobserver and properly limit parallelism. Closes #1744
2017-05-30 04:09:53 +00:00
warning: a `-j` argument was passed to Cargo but Cargo is also configured \
with an external jobserver in its environment, ignoring the `-j` parameter
[COMPILING] [..]
[FINISHED] [..]
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
Add a GNU make jobserver implementation to Cargo This commit adds a GNU make jobserver implementation to Cargo, both as a client of existing jobservers and also a creator of new jobservers. The jobserver is actually just an IPC semaphore which manifests itself as a pipe with N bytes of tokens on Unix and a literal IPC semaphore on Windows. The rough protocol is then if you want to run a job you read acquire the semaphore (read a byte on Unix or wait on the semaphore on Windows) and then you release it when you're done. All the hairy details of the jobserver implementation are housed in the `jobserver` crate on crates.io instead of Cargo. This should hopefully make it much easier for the compiler to also share a jobserver implementation eventually. The main tricky bit here is that on Unix and Windows acquiring a jobserver token will block the calling thread. We need to either way for a running job to exit or to acquire a new token when we want to spawn a new job. To handle this the current implementation spawns a helper thread that does the blocking and sends a message back to Cargo when it receives a token. It's a little trickier with shutting down this thread gracefully as well but more details can be found in the `jobserver` crate. Unfortunately crates are unlikely to see an immediate benefit of this once implemented. Most crates are run with a manual `make -jN` and this overrides the jobserver in the environment, creating a new jobserver in the sub-make. If the `-jN` argument is removed, however, then `make` will share Cargo's jobserver and properly limit parallelism. Closes #1744
2017-05-30 04:09:53 +00:00
}