Using Blocking APIs inside of Tokio Runtime
There are a large number of non-async APIs that users might want to use within a larger async flow. Having a guide on how to use blocking APIs inside of a Tokio runtime would be very useful.
Tokio's blocking APIs are still not fully fleshed out (https://github.com/tokio-rs/tokio/issues/629). It probably would be worth finishing the impl work before digging into this part of the documentation?
Definitely not worth writing docs that are likely to need to change. However, we know this is a use case that we'll need to cover. Do we figure out the location and scaffolding for it now?
We can figure out the flow now, for sure.
#49 includes some additional thoughts.
Related: https://github.com/tokio-rs/doc-push/issues/58#issuecomment-428034916
If a CPU intensive blocking task is currently running on a thread, will other partially complete non-blocking tasks that were on the same thread be moved to other threads, or will they wait indefinitely for the current task to complete?
In other words, if a thread is blocked in a task, will only new tasks be scheduled on other threads, or will partially complete old tasks also be migrated to other threads so they can finish ASAP?
partially completed old tasks will be migrated as well.
@carllerche So it's a valid strategy to block the event loop when I want each task to complete in the minimum possible time on a CPU core, instead of sharing CPU time on a separate blocking thread pool? i.e. If there are N CPU cores, I only want N CPU intensive blocking tasks to run at once. Other tasks should wait.
You should annotate those blocks w/ blocking.