Skip to content

available_parallelism: Add documentation for why we don't look at ulimit #144188

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 4, 2025
+3 −0
Merged

available_parallelism: Add documentation for why we don't look at ulimit #144188

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions library/std/src/thread/mod.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2012,6 +2012,9 @@ fn _assert_sync_and_send() {
/// which may take time on systems with large numbers of mountpoints.
/// (This does not apply to cgroup v2, or to processes not in a
/// cgroup.)
/// - It does not attempt to take `ulimit` into account. If there is a limit set on the number of
/// threads, `available_parallelism` cannot know how much of that limit a Rust program should
/// take, or know in a reliable and race-free way how much of that limit is already taken.
Comment on lines +2015 to +2017
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 If we did check ulimit, and made a guess based on it, getting it wrong and exceeding the value that is correct would just get the process killed anyways, right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd expect an error returned from thread::spawn, not getting killed (well, from the spawn builder, I think thread spawn would just panic). But, yes, I think that's right.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the distinction is deeper. ulimit restricts a different but related resource.

available_parallelism is essentially about how much cpu-time we get, not threads. It's just that users then turn around and use that to calculate the number of threads to make use of that cpu-time and oversubscription will be managed via sharing. This is quite obvious once you have multiple threadpools in a rust program independently using available_parallelism to size themselves (e.g. rayon + tokio).

ulimit is how many threads one may have globally, in total, even idle ones, and no oversubscription allowed.

Intended and existing usage of available_parallelism can't handle that discrepancy. It's not like runtimes check available_parallelism every time before they spawn a thread.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, that makes sense. So we might as well encounter whatever fate awaits us when we exceed the ulimit.

Copy link
Member

@workingjubilee workingjubilee Jul 20, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@joshtriplett I think this revision is probably fine as-is if Mark likes it.

But would it make more sense to jump off the8472's remark and note that the only truly "race-free" way (because it must be enforced by OS-level concurrency limits) to determine whether spawning a thread is possible within the OS-defined limits is to try to actually spawn the thread? Otherwise it's a TOCTOU problem, so it's true it simply does not make any attempt to guess. And then underscore that the value returned is not a guarantee that you can successfully spawn that many threads, merely that spawning that many threads may be useful.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was trying to say that I don't think not checking ulimit is really a limitation of the current implementation. It's out of scope.

We're not going to check if spawning a thread would run into memory or vma exhaustion either.

Maybe it'd make sense to list this in a more general "what this method isn't" clarification paragraph.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right, I probably didn't capture what you said correctly since it's a Nuance.

mostly I am agreeing in the direction of "what you said is correct, and in that sense this doesn't need to be a Linux-specific note".

///
/// On all targets:
/// - It may overcount the amount of parallelism available when running in a VM
Expand Down
Loading