recently when I was reading chapter 16 I thought about it. if library will use multithreading in its calculations, then it will be able to use all possible threads, and rust will panic when the library user is trying to use thread::spawn
I'm thinking of solving it using 2 functions, one is parallel , the other is not.
The pattern I've seen in libraries is to allow the user of the library to choose the level of parallelism desired. Not a binary choice, though it could be.
Example: WalkBuilder in ignore - Rust
Thanks for the answer, this is probably the best use case for me
I don't know what you are referring to, but you are probably misunderstanding something here. It's exceptionally rare for a well-designed program or library to exhaust the maximum number of thread handles, if this is what you are thinking.
I suspect that you may misunderstand what a thread is. The number of threads a process can have is not limited to the number of CPU cores or CPU “threads”. It's entirely normal for processes to have more threads than there are CPU cores, and the collection of all processes running on the machine has many more threads, most of which are asleep and not consuming any resources but memory and kernel table space.
Certainly a library should not create the maximum number of threads possible, but that is not to save capacity for other programs; it is because creating that many threads would waste resources and not gain additional parallelism.
When programs have a use for many threads running simultaneously to perform a large computation, they may consult std::thread::available_parallelism() to find out how many threads it is useful to create. (For example, rayon does this when creating its global thread pool.) However, if two libraries both do this, nothing blows up; rather, it's innocuous (if they are operating at different times) or a little less efficient than tweaking the thread counts down (if they are both using their threads for 100% continuous computation simultaneously).
But when a thread is just doing one intermittent job, like waiting for some particular category of event to happen, there is no need to worry about thread counts beyond the general principle applicable to many kinds of resources that if you can arrange to have fewer, that's probably more efficient usage.
Single process can spawn as many threads as the memory usage allows. Typical desktop machine can run tens of thousands of threads to run at the same time, though it may waste much CPU times for context switching. If you do want to spin more thread anyway, put more RAM into it.
Some OSes have a maximum limit on the total number of threads:
cat /proc/sys/kernel/threads-max
And there's also the ulimit
You're right, I really misunderstood what thread was. Thanks
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.