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

[joshtriplett]

No description provided.

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[workingjubilee]

🤔 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?

[Mark-Simulacrum]

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.

[the8472]

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.

[workingjubilee]

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

[workingjubilee]

@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.

[the8472]

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.

[workingjubilee]

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".