30 releases

0.1.31 Apr 22, 2024
0.1.28 Feb 8, 2024
0.1.27 Oct 10, 2023
0.1.26 Feb 28, 2023
0.1.6 Jul 12, 2017

#27 in Concurrency

Download history 863417/week @ 2024-03-01 940667/week @ 2024-03-08 968273/week @ 2024-03-15 1013099/week @ 2024-03-22 983520/week @ 2024-03-29 994454/week @ 2024-04-05 1110712/week @ 2024-04-12 1167467/week @ 2024-04-19 1110377/week @ 2024-04-26 1099839/week @ 2024-05-03 1110647/week @ 2024-05-10 1107057/week @ 2024-05-17 1064333/week @ 2024-05-24 1226641/week @ 2024-05-31 1203777/week @ 2024-06-07 979220/week @ 2024-06-14

4,675,740 downloads per month
Used in 8,128 crates (22 directly)




An implementation of the GNU Make jobserver for Rust.




Add this to your Cargo.toml:

jobserver = "0.1"


This project is licensed under either of

at your option.


Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in jobserver-rs by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.


An implementation of the GNU make jobserver.

This crate is an implementation, in Rust, of the GNU make jobserver for CLI tools that are interoperating with make or otherwise require some form of parallelism limiting across process boundaries. This was originally written for usage in Cargo to both (a) work when cargo is invoked from make (using make's jobserver) and (b) work when cargo invokes build scripts, exporting a jobserver implementation for make processes to transitively use.

The jobserver implementation can be found in detail online but basically boils down to a cross-process semaphore. On Unix this is implemented with the pipe syscall and read/write ends of a pipe and on Windows this is implemented literally with IPC semaphores. Starting from GNU make version 4.4, named pipe becomes the default way in communication on Unix. This crate also supports that feature in the sense of inheriting and forwarding the correct environment.

The jobserver protocol in make also dictates when tokens are acquired to run child work, and clients using this crate should take care to implement such details to ensure correct interoperation with make itself.


Connect to a jobserver that was set up by make or a different process:

use jobserver::Client;

// See API documentation for why this is `unsafe`
let client = match unsafe { Client::from_env() } {
    Some(client) => client,
    None => panic!("client not configured"),

Acquire and release token from a jobserver:

use jobserver::Client;

let client = unsafe { Client::from_env().unwrap() };
let token = client.acquire().unwrap(); // blocks until it is available
drop(token); // releases the token when the work is done

Create a new jobserver and configure a child process to have access:

use std::process::Command;
use jobserver::Client;

let client = Client::new(4).expect("failed to create jobserver");
let mut cmd = Command::new("make");
client.configure(&mut cmd);


This crate makes no attempt to release tokens back to a jobserver on abnormal exit of a process. If a process which acquires a token is killed with ctrl-c or some similar signal then tokens will not be released and the jobserver may be in a corrupt state.

Note that this is typically ok as ctrl-c means that an entire build process is being torn down, but it's worth being aware of at least!

Windows caveats

There appear to be two implementations of make on Windows. On MSYS2 one typically comes as mingw32-make and the other as make itself. I'm not personally too familiar with what's going on here, but for jobserver-related information the mingw32-make implementation uses Windows semaphores whereas the make program does not. The make program appears to use file descriptors and I'm not really sure how it works, so this crate is not compatible with make on Windows. It is, however, compatible with mingw32-make.