Handle.rs

/// Handle to the runtime.
///
/// The handle is internally reference-counted and can be freely cloned. A handle can be
/// obtained using the [`Runtime::handle`] method.
///
/// [`Runtime::handle`]: crate::runtime::Runtime::handle()
#[derive(Debug, Clone)]
// When the `rt` feature is *not* enabled, this type is still defined, but not
// included in the public API.
pub struct Handle {
    pub(crate) inner: scheduler::Handle,
}
#[derive(Debug, Clone)]
pub(crate) enum Handle {
    #[cfg(feature = "rt")]
    CurrentThread(Arc<current_thread::Handle>),

    #[cfg(feature = "rt-multi-thread")]
    MultiThread(Arc<multi_thread::Handle>),

    // TODO: This is to avoid triggering "dead code" warnings many other places
    // in the codebase. Remove this during a later cleanup
    #[cfg(not(feature = "rt"))]
    #[allow(dead_code)]
    Disabled,
}
/// Handle to the multi thread scheduler
pub(crate) struct Handle {
    /// Task spawner
    pub(super) shared: worker::Shared,

    /// Resource driver handles
    pub(crate) driver: driver::Handle,

    /// Blocking pool spawner
    pub(crate) blocking_spawner: blocking::Spawner,

    /// Current random number generator seed
    pub(crate) seed_generator: RngSeedGenerator,

    /// User-supplied hooks to invoke for things
    pub(crate) task_hooks: TaskHooks,
}
/// Handle to the current thread scheduler
pub(crate) struct Handle {
    /// Scheduler state shared across threads
    shared: Shared,

    /// Resource driver handles
    pub(crate) driver: driver::Handle,

    /// Blocking pool spawner
    pub(crate) blocking_spawner: blocking::Spawner,

    /// Current random number generator seed
    pub(crate) seed_generator: RngSeedGenerator,

    /// User-supplied hooks to invoke for things
    pub(crate) task_hooks: TaskHooks,

    /// If this is a `LocalRuntime`, flags the owning thread ID.
    pub(crate) local_tid: Option<ThreadId>,
}

在上一章《理解 Rust 异步编程：从 Send/Sync 到 Future、Waker、Poll》中，我们已经搞清楚了几件事：

• async fn 在编译期会被降级成一个 Future 状态机；
• 这个状态机通过 poll 一步步向前推进；
• Pin 负责保证状态机在内存中的位置不被随意移动；
• Waker 负责在 I/O、定时器等事件就绪时把任务“叫醒”。 但有了这些“零件”还不够，这些被编译出来的 Future 谁来不断 poll？谁来管理时间和 I/O？谁来调度成千上万的任务？ 这一层，就是本篇要讲的主角：异步运行时（Asynchronous Runtime）。 在这一章，我们会围绕三个问题展开：

为什么会出现repr(...)

Rust 默认使用 优化布局（optimized layout）：

• 字段顺序可以被重排（为了减少 padding）
• 对齐由平台 ABI+ Rust 自己的规则决定
• 枚举的表示（tag、payload）是可优化的，不保证稳定
• ZST、DST 会被做特殊处理

我们在代码里面构造的结构体：

struct Foo {
     a: u8,
     b: u32,
     c: u16, 
}

codemap

1. 先把 runtime/mod.rs 的文档看完（尤其是“Detailed runtime behavior”那段）Docs.rs
2. 然后按这个顺序看代码：
   1. runtime.rs + builder.rs + config.rs
   2. handle.rs + context.rs
   3. park.rs
   4. scheduler/ + runtime::task（配合 coop 文档一起看）
   5. driver/ + io/ + time/（把 reactor + timer mental model补齐）
   6. 最后再看 metrics.rs、task_hooks.rs、dump.rs 这些“观测层”。

在学习 Tokio 与 Rust 异步编程的过程中，我时常会遇到各种 unsafe 语法与底层原语，实现方式也常常带着“黑魔法”般的精巧与惊奇。为了系统地消化这些内容，我计划开启一个全新的系列，用于记录自己在阅读 Rust 黑魔法（底层实现、编译器行为、不安全代码）过程中产生的一系列思考与笔记。 除了 Rust 本身，本系列也会同步梳理相关的计算机基础知识，包括内存模型、并发原理、数据布局、指针语义、调度器机制等与“黑魔法”紧密联系的主题。本系列不强调固定的章节结构，将以探索式写作为主。至于何时完结，则取决于我能否把整个 unsafe 体系贯穿得足够完整。

我们在随笔七和随笔八中提到过，异步编程的本质就是在多个任务共享一个时间段，并且我们还介绍了什么是Send&Sync，并表明了其在rust编程中的地位，那么今天，我们进一步深入Rust异步编程，了解Rust异步编程靠的是什么维持，需要什么工具去支撑，在Send和Sync的基础上，如何保证并发安全？ 这是一个新系列，并打算开展3篇内容介绍，以下是系列大纲：

1. 《理解 Rust 异步编程：从Send/Sync到Future、Waker、Poll》着重介绍Rust异步编程的基本工具和基本的类型
2. 《理解 Rust 异步编程：深入Tokio，理解Rust异步运行时的灵魂》着重介绍Rust异步编程中的异步runtime，并且深入研究Tokio的基本原理
3. 《理解 Rust 异步编程：构建一个高并发事件系统，从 Tokio 基础到完整限速框架》在最后一篇我们用上面两篇的知识构建一个高性能应用 通过这个系列，我们将从语言抽象到运行时实现，逐步理解 Rust 异步的安全性来源、性能边界，以及它在“高并发”场景下的真实力量。 那么，在进入 runtime 之前，我们首先得问：

今天来谈谈Rust里面的Sync和Send，在随笔七里面我们提到这两个概念，今天我们来详细的说一下。这两个trait是rust异步编程的主要基石之一。我们首先看看定义：

1. Send Send 表示一个类型的所有权可以安全地在线程之间转移。
2. Sync Sync 表示一个类型的不可变引用（&T）可以安全地在线程之间共享。 只有同时实现这两者，才能在多线程环境下共享数据，看着定义我们会感到有点疑惑，接下来我们用例子说明。

在前面一章我们介绍了什么是OOP和Rust思想上的区别，以及Rust的一些基础语法和核心思想。 本章我们围绕OOP的Object和Interface,Rust的Struct和Trait，介绍他们的基础语法以及核心思想，并且对其进行对比以及优势比较。

OOP

对于OOP来说，Object和Interface几乎熟悉得不能再熟悉了，几乎所有的编程设计都是围绕Object，OOP的三大基本原则：

我们前面介绍了Arc<Mutex<T>>这个东西，本篇我们以此为引子，打开Rust编程中异步编程的门。

什么是异步编程

几乎每一个编程语言都能做到异步编程，那么什么是异步编程呢？这里举一个例子：

1. A要去做n件事情
2. 这些事情并不会立马出结果，并且需要等待，每件事情假设处理的时间为m，等待的时间为w
3. 要在尽可能短的时间内做完并收集起来（假设每件事情收集完成的速度为t）
4. 已知这些事情并没有关联 那么假设我们一件事情一件事情的做，那么所有事情做完就等于n * (m + w + t)，公式看起来不大，但是如果时间单位是秒，n是一个很大的数(比如说1百万)，那么处理起来就很吓人了，从上面我们得到一个条件，就是每一件事情没有关联，那么我们就可以在处理这些事情的时候，在等待期间就可以做其他事情，那么按照这样的思路做，时间就变成了(n * m) + w + (n * t)（调度的时间在这里为了简化所以忽略不计），这样看时间是不是少了一个数量级，如果我们加多一些人手来做，假设添加了p个人，那么时间就变成了(n * (m + t)) / p + w，这样是不是又少了一个数量级。所以这个就是异步编程的核心思想： 协作式调度与非阻塞等待。任务在遇到需要等待的操作（如网络请求）时，会主动让出执行权，这样同一个工作线程就可以立刻去处理其他准备就绪的任务。这极大地提高了在 I/O 密集型场景下的资源利用率。 这里只是大致的描述一下异步编程，异步编程本身又非常多的概念，比如说并行，并发，同步，异步，资源调度等等。这些概念可以自行了解。接下来，我们介绍一下操作异步的基本单位：协程，与之相关的：线程和进程。

我们在随笔五中提到过Rc和RefCell的概念，这两个工具给复杂的变量引用场景给予了强大的支持，这里有个问题，我们首先看看下面这一段代码：

use std::rc::Rc;
use std::thread;

fn main() {
    let data = Rc::new(5);
    let data_clone = Rc::clone(&data);
    
    thread::spawn(move || {
        println!("Data from new thread: {}", data_clone);
    });
}