mcpField
R
rust-async-internals

rust-async-internals

github.com/mohitmishra786開発269480 回インストール18 週間前に更新
リポジトリ

rust-async-internals について

Rust の非同期処理の内部構造とデバッグ上の注意点を解説する、エージェント向けガイドです。Future のポーリング、Pin、Tokio タスク、ブロッキング呼び出し、select! と join! の落とし穴を扱います。

主な機能

  1. 01Future と poll の実行モデル
  2. 02Pin と Unpin の役割
  3. 03Tokio のタスクモデル
  4. 04tokio-console による非同期タスクの確認
  5. 05非同期処理でのブロッキングと select! の注意点

活用シーン

  1. 01async/await の実行方法の理解
  2. 02非同期プログラムの性能問題の調査
  3. 03Tokio タスクや waker の問題の確認
  4. 04ブロッキング呼び出しや select! の分岐キャンセルの回避

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mohitmishra786/low-level-dev-skills --skill rust-async-internals

インストール後、Claude Code で/rust-async-internalsを入力して読み込まれたか確認します。

詳細

Rust Async 内部の仕組み

目的

Rust の async/await の内部の仕組みをエージェント向けに説明します。Future トレイトとポーリングループ、自己参照型における Pin/Unpin、tokio のタスクモデル、tokio-console を使った非同期スタックトレースの診断、waker リークの発見、よくある select!/join! の落とし穴を扱います。

トリガー

  • 「Rust の async/await は実際にはどのように動作しますか?」
  • 「Rust の非同期処理における Pin と Unpin とは何ですか?」
  • 「非同期コードが遅いです。どうすればプロファイルできますか?」
  • 「非同期タスクをデバッグするために tokio-console を使う方法を教えてください」
  • 「非同期処理の中にブロッキング呼び出しがあります。どうすればよいですか?」
  • 「select! はどのように動作し、どんな落とし穴がありますか?」

ワークフロー

1. Future トレイト — poll モデル
// std::future::Future (simplified)
pub trait Future {
    type Output;
    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output>;
}

pub enum Poll<T> {
    Ready(T),    // computation done, T is the result
    Pending,     // not ready yet, waker registered, will be polled again
}

実行モデル:

  1. .await を呼び出すと、future の poll() が呼び出されます
  2. Pending の場合:現在のタスクが waker を登録し、ランタイムに処理を譲ります
  3. waker がトリガーされると(I/O の準備完了、タイマーの発火など)、ランタイムが再度ポーリングします
  4. Ready(val) の場合:.await 式は val と評価されます
2. シンプルな Future の実装
use std::{
    future::Future,
    pin::Pin,
    task::{Context, Poll},
    time::{Duration, Instant},
};

struct Delay { deadline: Instant }

impl Delay {
    fn new(dur: Duration) -> Self {
        Delay { deadline: Instant::now() + dur }
    }
}

impl Future for Delay {
    type Output = ();

    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<()> {
        if Instant::now() >= self.deadline {
            Poll::Ready(())
        } else {
            // Register the waker — runtime calls waker.wake() to re-poll
            // In production: register with I/O reactor or timer wheel
            let waker = cx.waker().clone();
            let deadline = self.deadline;
            std::thread::spawn(move || {
                let now = Instant::now();
                if deadline > now {
                    std::thread::sleep(deadline - now);
                }
                waker.wake();  // notify runtime to re-poll
            });
            Poll::Pending
        }
    }
}

// Usage
async fn main() {
    Delay::new(Duration::from_secs(1)).await;
    println!("Done");
}
3. Pin と Unpin

Pin<P> は、ポインター P の指す値が移動するのを防ぎます。これは、非同期状態マシンに自己参照ポインター(future が格納されている同じ構造体内への参照)が含まれるため重要です。

// Why Pin is needed: async fn compiles to a state machine struct
// that may have self-references across await points

async fn example() {
    let data = vec![1, 2, 3];
    let ref_to_data = &data;              // reference into same stack frame
    some_async_op().await;                // suspension point
    println!("{:?}", ref_to_data);       // reference still used after suspend
}
// The state machine stores both `data` and `ref_to_data`.
// If the struct were moved, `ref_to_data` would dangle.
// Pin<&mut State> prevents moving the state machine.

// Unpin: a marker trait for types that are safe to move even when pinned
// Most types implement Unpin automatically
// Futures generated by async/await do NOT implement Unpin

// Creating a Pin from Box (heap allocation → safe)
let boxed: Pin<Box<dyn Future<Output = ()>>> = Box::pin(my_future);

// Pinning to stack (unsafe, use pin! macro)
use std::pin::pin;
let fut = pin!(my_future);
fut.await;   // or poll it directly
4. tokio のタスクモデル
use tokio::task;

// Spawn a task (runs concurrently on the runtime thread pool)
let handle = tokio::spawn(async {
    // ... async work ...
    42
});
let result = handle.await.unwrap();  // wait for completion

// spawn_blocking — for CPU-bound or blocking I/O
let result = task::spawn_blocking(|| {
    // runs on a dedicated blocking thread pool
    std::fs::read_to_string("big_file.txt")
}).await.unwrap();

// yield to runtime (cooperative multitasking)
tokio::task::yield_now().await;

// LocalSet — for !Send futures (single-threaded)
let local = task::LocalSet::new();
local.run_until(async {
    task::spawn_local(async { /* !Send future */ }).await.unwrap();
}).await;
5. tokio-console — 非同期タスクインスペクター
# Cargo.toml
[dependencies]
console-subscriber = "0.3"
tokio = { version = "1", features = ["full", "tracing"] }
// main.rs
fn main() {
    console_subscriber::init();  // must be called before tokio runtime
    tokio::runtime::Builder::new_multi_thread()
        .enable_all()
        .build()
        .unwrap()
        .block_on(async_main());
}
# Install tokio-console CLI
cargo install --locked tokio-console

# Run your app with tracing enabled
RUSTFLAGS="--cfg tokio_unstable" cargo run

# In another terminal, connect tokio-console
tokio-console

# tokio-console shows:
# - Running tasks with their names, poll times, and wakeup counts
# - Slow tasks (high poll duration = blocking in async!)
# - Tasks that have been pending for a long time (stuck?)
# - Resource contention (mutex/semaphore wait times)
6. 非同期処理におけるブロッキング — よくある間違い
// WRONG: blocking call in async context blocks entire thread
async fn bad() {
    std::thread::sleep(Duration::from_secs(1));  // blocks runtime thread!
    std::fs::read_to_string("file.txt").unwrap(); // blocking I/O blocks runtime!
}

// CORRECT: use async equivalents
async fn good() {
    tokio::time::sleep(Duration::from_secs(1)).await;   // async sleep
    tokio::fs::read_to_string("file.txt").await.unwrap(); // async I/O
}

// CORRECT: if you must block, use spawn_blocking
async fn with_blocking() {
    let content = tokio::task::spawn_blocking(|| {
        heavy_cpu_computation()   // runs on blocking thread pool
    }).await.unwrap();
}
7. select! と join! の落とし穴
use tokio::select;

// select! — complete when FIRST branch completes, cancels others
select! {
    result = fetch_a() => println!("A: {:?}", result),
    result = fetch_b() => println!("B: {:?}", result),
    // Pitfall: the LOSING branches are DROPPED immediately
    // If fetch_a wins, fetch_b's future is dropped (and its state machine cleaned up)
    // This is correct and safe — but can be surprising
}

// join! — wait for ALL to complete
let (a, b) = tokio::join!(fetch_a(), fetch_b());

// Biased select (always check first branch first)
loop {
    select! {
        biased;                        // prevents fairness, checks in order
        _ = shutdown_signal.recv() => break,
        msg = queue.recv() => process(msg),
    }
}

// select! with values from loop (use fuse)
let mut fut = some_future().fuse();   // FusedFuture: safe to poll after completion
loop {
    select! {
        val = &mut fut => { /* ... */ break; }
        _ = interval.tick() => { /* periodic work */ }
    }
}

関連スキル

  • 非同期 Rust プログラムの GDB/LLDB デバッグには skills/rust/rust-debugging を使用します
  • 非同期スタックフレームを含む cargo-flamegraph には skills/rust/rust-profiling を使用します
  • C++20 コルーチンとの比較には skills/low-level-programming/cpp-coroutines を使用します
  • 非同期コンテキストにおけるメモリー順序には skills/low-level-programming/memory-model を使用します

コメント