mirror of
https://github.com/tokio-rs/tokio.git
synced 2026-08-19 00:00:09 +02:00
Carl Lerche
911a0efa87
Previously, `runtime::Handle` was a single struct composed of the internal handles for each runtime component. This patch splits the `Handle` struct into a `HandleInner` which contains everything **except** the task scheduler handle. Now, `HandleInner` is passed to the task scheduler during creation and the task scheduler is responsible for storing it. `Handle` only needs to hold the scheduler handle and can access the rest of the component handles by querying the task scheduler. The motivation for this change is it now enables the multi-threaded scheduler to have direct access to the blocking spawner handle. Previously, when spawning a new thread, the multi-threaded scheduler had to access the blocking spawner by accessing a thread-local variable. Now, in theory, the multi-threaded scheduler can use `HandleInner` directly. However, this change hasn't been done in this PR yet. Also, now the `Handle` struct is much smaller. This change is intended to make it easier for the multi-threaded scheduler to shutdown idle threads and respawn them on demand.
24 lines
677 B
Rust
24 lines
677 B
Rust
//! Abstracts out the APIs necessary to `Runtime` for integrating the blocking
|
|
//! pool. When the `blocking` feature flag is **not** enabled, these APIs are
|
|
//! shells. This isolates the complexity of dealing with conditional
|
|
//! compilation.
|
|
|
|
mod pool;
|
|
pub(crate) use pool::{spawn_blocking, BlockingPool, Mandatory, Spawner, Task};
|
|
|
|
cfg_fs! {
|
|
pub(crate) use pool::spawn_mandatory_blocking;
|
|
}
|
|
|
|
mod schedule;
|
|
mod shutdown;
|
|
mod task;
|
|
pub(crate) use schedule::NoopSchedule;
|
|
pub(crate) use task::BlockingTask;
|
|
|
|
use crate::runtime::Builder;
|
|
|
|
pub(crate) fn create_blocking_pool(builder: &Builder, thread_cap: usize) -> BlockingPool {
|
|
BlockingPool::new(builder, thread_cap)
|
|
}
|