Using ThreadPool for blocking I/O?

[couchand]

Is it a legitimate use of this crate's ThreadPool for managing blocking I/O? The only reference I can find in any documentation is a terse warning on the top-level join docs:

If you do perform I/O, and that I/O should block (e.g., waiting for a network request), the overall performance may be poor.

What does "overall performance may be poor" mean specifically?

Also, is that warning:

• Limited to the top-level join?
• Also applicable to the join associated function on ThreadPool?
• Also applicable to scope and spawn?

Is there an acceptable usage pattern for blocking I/O? Is the use of rayon for concurrent blocking I/O to be avoided entirely? If so, what crate should I look to for a thread pool for blocking I/O?

Thanks!

[cuviper]

That warning applies to anything that executes in the thread pool. If you block in a rayon thread for any non-rayon reason (e.g. locking a mutex or performing I/O), that thread will not be able to participate in work-stealing. We say the performance may be poor due to wasted potential, because this blocked thread will be idle instead of processing other tasks in the pool.

If you can adapt your I/O to async futures, the tokio and async-std runtimes both use their own thread pools. We may eventually add Future support in rayon too -- #679.

[couchand]

That makes sense, as the main purpose of this library is data parallelism, not thread management. I'd recommend clarifying that warning, and promoting it to the FAQ or the top-level module documentation. I'm happy to open a PR, though I'm probably not the most qualified to do so.

There's lots to be said for futures-based I/O, but not every problem is best solved with that approach. For this particular use-case, I'm specifically looking for a thread pool to manage blocking I/O, and was curious if rayon's pool was appropriate.

Thanks for your quick response!