I want to run some long running blocking code with futures 0.3.
I thought about using 2 ThreadPool, one for my blocking futures and 1 for my non-blocking ones. Is it the right thing to do?
There was some recent discussion around this on
https://github.com/rust-lang-nursery/futures-rs/issues/1517
IMO futures::executor::ThreadPool could be making internal tradeoffs that make it less appropriate for running blocking code on since it's intended for executing futures, and it would be better to have something explicitly intended for running a blocking computation and returning a handle to the result.
But, as far as I know at the moment, ThreadPool isn't doing anything that would adversely impact blocking code running on it, so using it should work fine.
2 Likes
When using blocking tasks with thread pools, make sure that they do not block waiting for each other. Otherwise, it is very easy to end up with a deadlock where the entire thread pool is waiting for more tasks to be scheduled, but no more tasks will be scheduled if the current ones do not complete.
As far as I know, that's the main correctness concern to keep in mind. Aside from that, blocking tasks on a thread pool should work mostly like blocking tasks on dedicated threads, just possibly executing slower (if the CPU does not stay busy because the blocking thread pool is too small) or faster (if the CPU oversubscription of one task per thread was slowing things down).
2 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.