コルーチンとステートマシン変換の原理

コルーチンとは──中断と再開を持つ関数

通常の関数（サブルーチン）は呼ばれたら最後まで走り、return で一度だけ制御を返します。コルーチンはこの非対称を崩し、実行の途中で自発的に制御を手放し（サスペンド）、後でその続きから走り直せる（レジューム）関数です。鍵は「どこまで進んだか」と「途中の変数」を中断の間も保存することにあります。この保存方法の違いが、スタックフルとスタックレスという2系統を生みます。本記事は両者の原理と、async/await がコンパイラによって**有限状態機械（FSM）**へ変換される仕組み、そしてサスペンド／レジュームの実コストを解剖します。

スタックフルコルーチン──専用スタックを丸ごと持つ

スタックフルコルーチンは、各コルーチンに独立した実行スタックを割り当てます。中断時にはスタックポインタと一部レジスタを退避し、再開時に復元するだけ。スタックがそのまま残るので、a() が b() を呼び b() が c() を呼んだ深い入れ子の c() の中からでも、丸ごと中断できます。

• 利点：中断点に制約がない。ライブラリ関数の奥からでも yield でき、普通の同期コードをほぼそのまま並行化できる。Go のゴルーチン、各言語のファイバ／グリーンスレッドがこの系統。
• 欠点：スタックを事前に確保する必要があり、1コルーチンあたり数KB〜数十KBを占める。大量に作るとメモリ消費が膨らむため、可変長スタックや分割スタックで緩和する。

中断・再開はスタック切り替えに近く、コンテキストスイッチの軽量版と見なせます。ただしカーネルを介さずユーザー空間で完結する点が、後述のコスト差を生みます。

スタックレスコルーチン──状態を構造体に畳み込む

スタックレスコルーチンは専用スタックを持ちません。代わりに中断点をまたいで生き残る変数だけを、ヒープ上の1つの状態オブジェクトに保存します。実行位置は「次にどこから再開するか」を表す状態番号で表現します。

この方式の制約は重要です。中断できるのはそのコルーチン関数の本体内だけで、そこから呼んだ普通の関数の途中では中断できません（呼ばれた側にはスタックが残らないため）。中断したい地点を含む関数は、すべて async として明示的に書く必要があります。これが「async は伝播する（colored function 問題）」と呼ばれる現象の正体です。

• 利点：保存するのは生存変数だけなので極めて軽量。1インスタンスが数十バイト〜で済み、数百万個でもメモリに収まる。
• 欠点：中断点が関数本体に限定され、呼び出しチェーン全体に async が波及する。

async/await はどうステートマシンになるか

async/await の正体は、コンパイラによる機械的なコード変換です。手順を原理から追います。

1. 分割点の特定：関数内の各 await を境界に、コードを区切る。await の前後で制御が外に出て戻ってくるため、ここが状態の切れ目になる。
2. 生存変数の抽出：ある await を越えて後で使われる変数（ローカル変数・引数）を割り出す。これらは中断中も保持が必要なので、状態構造体のフィールドにする。逆に await を越えない一時変数は構造体に入れず通常のスタックで済む。
3. 状態番号の付与：各再開地点に整数の状態番号を割り当てる（0=開始、1=1つ目のawait後、…、最終=完了）。

変換後の resume（再開関数）は、おおむね「状態番号で分岐し、対応する区間を実行し、次の await で状態番号を更新して戻る」というループになります。擬似コードで示します。

async fn fetch_and_sum(url):
    a = await get(url)      # 中断点1
    b = await parse(a)      # 中断点2
    return a.len + b

これは次のような状態機械へ変換されます。

struct State:
    state: int = 0          # 再開位置
    a, b: ...               # 中断をまたぐ生存変数だけを保持

fn resume(self, input):
    switch self.state:
      case 0:
        start get(url); self.state = 1; return Pending
      case 1:               # get 完了で再開
        self.a = input
        start parse(self.a); self.state = 2; return Pending
      case 2:               # parse 完了で再開
        self.b = input
        self.state = DONE
        return Ready(self.a.len + self.b)

ポイントは、スタックを使わずに「続き」を表現していることです。再開に必要な情報がすべて State 構造体に入っているので、関数からいったん完全に抜けても（スタックが巻き戻っても）、構造体さえ保持していれば resume を呼び直すだけで続きから走ります。これがスタックレスたるゆえんです。状態番号は「次に飛ぶ case ラベル」、構造体は「畳んだスタックフレーム」に相当します。

スタックフルとスタックレスの比較

サスペンド／レジュームのコストと適用領域

スタックレスの中断・再開は、本質的には状態番号の読み書きと switch 分岐、構造体フィールドへのアクセスです。カーネルへの遷移もスタック切り替えもなく、関数呼び出し1回程度のコストに収まります。これがコンテキストスイッチ（レジスタ群の退避・復元、場合によりTLBやキャッシュの汚染、カーネル往復で数百ns〜マイクロ秒級）と比べて桁違いに安い理由です。スタックフルでも、ユーザー空間で完結すればカーネルのスイッチより十分安価です。

この安さが効くのは、待ちが多く計算が少ないワークロード——典型的にはネットワークI/Oの多い高並行サーバーです。1接続=1スレッドではスレッド数ぶんのスタックとスイッチコストが積み上がりますが、1接続=1コルーチンなら、I/O待ちのたびに安価に他のコルーチンへ譲れます。コルーチンの中断と完了通知を結びつけるのがイベント駆動I/Oモデルで、I/Oが完了したら対応する状態機械の resume を呼ぶ、という形で噛み合います。

まとめ