Cargo does not return tokens immediately after finishing a single job

[mgorny]

Problem

The current jobserver implementation in Cargo is built to consume as much tokens as possible, and hold on to them for as long as there is work to do. This means that as soon as a single cargo build capable of using all the jobserver jobs is started, it can block other processes from acquiring a single token for a long time, effectively blocking them from starting.

This goes against the spirit of jobserver, which is to run jobs in an (approximate) round-robin fashion. It also penalizes concurrent builds with other tasks that cannot saturate the CPUs on their own: normally they would run n < nproc jobs in parallel with nproc - n jobs used by Cargo; however, due to Cargo's implementation, cargo will run with nproc jobs and finish first, then the remaining jobs will slowly toil with n < nproc jobs, leaving the remaining CPUs idle. This is also a major pain for interactively running separate build processes in parallel, as you can't start any other process without acquiring the first token for it, so the user needs to wait a long time for cargo to free a single token.

Steps

1. Start a jobserver (e.g. steve).
2. Start a cargo build under the jobserver (e.g. via stevie cargo build).
3. Try to start another job needing a jobserver token (e.g. stevie echo 1).

Normally (i.e. with a jobserver implementation of make or ninja) the task should complete within seconds. However, when cargo is used, it won't start until cargo finishes building.

Possible Solution(s)

Acquire a single token for every job that's about to be run, and release it as soon as the job finishes. Do not hold tokens longer than necessary.

Notes

No response

Version

cargo 1.97.1 (c980f4866 2026-06-30) (gentoo)

[epage]

Interesting. I've not checked the code but #7786 makes it sound like the opposite is happening and requests what you've observed.

[mgorny]

For the record, I've been testing with uv to confirm. Building it (even in debug mode) takes a few minutes, and during that time the tokens are held nonstop.

[Suryansh-Dey]

The root cause seems to be that Cargo recycles tokens internally instead of returning them to the jobserver.

Would a desirable solution be to drop the token back to the OS pipe immediately whenever a child rustc process exits? When Cargo has another package ready to compile, it must get back in line and request a new token from the OS.

This would give the necessary back-and-forth round-robin behavior, allowing the OS to fairly distribute tokens to other waiting processes and solving the parallel job starvation issue.

Or may be because Rust builds a so slow that trying two parallel builds with race for token is never a good idea?

[mgorny]

Would a desirable solution be to drop the token back to the OS pipe immediately whenever a child rustc process exits? When Cargo has another package ready to compile, it must get back in line and request a new token from the OS.

Yes, that's how a jobserver normally works. One token, one (reasonably sized) job.

[mgorny]

Interesting. I've not checked the code but #7786 makes it sound like the opposite is happening and requests what you've observed.

I've also confirmed with Firefox. Of course Firefox is big, but whenever a Rust part hits the pipeline, everything else is blocked (including building other packages).