RFC-2394: async_await

注意: 正確性は重視していない意訳なので、正確に知りたい人は原文を参照のこと

関連RFC

------

開始日: 2018-03-30

1. 要約

2. 動機

ハイパフォーマンスなネットワークサーバを書く場合には、非同期I/Oが多用される

ただ、現状のRustだと非同期I/Oコードが書き難いので、もっと改善したい

Rustの非同期I/Oの歴史:

1.0より前: グリーンスレッド => 全てのランタイムに組み込むには重いので削除

1.0より後:

非同期操作を抽象的に表現するためのcrateで、Rustの非同期I/Oモデルの中核となる

ただ幸運なことに、future抽象自体はRustに適している

=> 適切な糖衣構文さえあれば良さそう

=> 他の言語でも良く使われているasync/awaitを導入しよう

async/awaitとfuturesの組み合わせは強力

非同期I/Oだけではなく、より汎用的な非同期ないし並行抽象を表現するために利用可能

3. ガイドレベルの説明

3-1. async関数

code:rust

async fn function(argument: &str) -> usize {

// ...

}

以下はその例:

code:rust

async fn print_async() {

println!("Hello from print_async")

}

fn main() {

let future = print_async();

println!("Hello from main"); // "Hello from main"が表示

futures::block_on(future); // "Hello from print_async"が表示

}

3-1-1. async ||クロージャ

code:rust

fn main() {

let closure = async || {

println!("Hello from async closure.");

};

println!("Hello from main"); // "Hello from main"が出力

let future = closure();

println!("Hello from main again"); // "Hello from main again"が出力

futures::block_on(future): // "Hello from async closure."が出力

}

3-2. ayncブロック

code:rust

let my_future = async {

printlN!("Hello from an async block");

};

code:rust

async { /* body */ }

// is equivalent to

(async || { /* body /* })()

3-3. コンパイラ組み込みのawait!マクロ

コンパイラに組み込みのマクロ

futureの計算を"停止"するために利用でき、制御を呼び出し元に委譲(yield)する

code:rust

// future: impl Future<Output = usize>

let n = await!(future);

将来的には、専用の構文になるかもしれないけれど、未解決の疑問があるので、まだ組み込みマクロ扱いにしている。

4. リファレンスレベルの説明

4-1. キーワード

4-2. async関数、クロージャ、ブロックの返り値

async関数の返り値の型は、コンパイラによって生成されるユニークな無名型（クロージャの型と似ている）

関数内の全ての"yield point"に、対応するvariantが存在する

各variantには、その地点から制御を再開するために必要な情報（状態）、を保持する

関数が呼び出されると、全ての引数を含んだ初期状態、が返される

4-2-1. トレイト境界

ポーリングによって、関数の状態が進む

理由: このfutureは内部参照を持つ可能性があり、それは決してmoveされる必要がないことを意味するため

4-3. 無名futureに捕捉されるライフタイム

code:rust

async fn foo(arg: &str) -> usize { ... }

↑は↓と等しい。

code:rust

fn foo<'a>(arg: &'a str) -> impl Future<Output = usize> + 'a { ... }

4-3-1. "initialization"パターン

async関数の引数の一部は、初期化処理にだけ使用し、返り値のfutureには含めたくないことがある

無駄に厳しいライムタイムを制約を回避するため

async関数では、この"initialization"パターンを表現することは不可能

ただし、以下のような方法で実現は可能

code:rust

fn foo<'a>(arg1: &'a str, arg2: &str) -> impl Future<Output = usize> + 'a {

async move {

// この関数の非同期部分

}

}

4-4. awaitの展開

code:rust

let mut future = IntoFuture::into_future($expression);

let mut pin = unsafe { Pin::new_unchecked(&mut future) };

loop {

match Future::poll(Pin::borrow(&mut pin), &mut ctx) {

Poll::Ready(item) => break item,

Poll::Pending => yield,

}

}

これは本来の展開とは異なる。

4-5. asyncとmoveの順序

code:rust

async move {

// body

}

5. 欠点

一行要約: 大きな機能追加だから導入が大変だし、入れてしまうともう後戻りができなくなってしまう

async/await構文の追加は、1.0リリース以来で、言語に対する最も大きな変更

機能単位を細かく区切って慎重に進めていく

私たちは、書きやすい非同期I/Oソリューションは、高パフォーマンスなネットワークサービスの分野でのRustの成功を支えるために不可欠だと信じている

2018年のゴールの一つ

もしこれらの安定化後に、後戻りすることになったら、それはかなりコスト高

非同期プログラミング用の他のメカニズムを追加することも同様

他にも、このRFCでの選択に纏わる細かい欠点はいくつかある

その詳細と選択の妥当性は次節で取り上げる

6. 妥当性と代替案

6-1. 返り値 (impl Future<Output = T>ではなくT)

非同期関数の返り値の型をどうするかは、複雑な問題

二種類の型が考えれる:

外部返り値型: 関数呼び出し時に、実際に呼び出し元に返される型

6-1-1. ライフタイム省略問題

外部返り値型を採用した場合の問題の話:

ただし、async関数が返すfutureは、全ての入力引数を捕捉し、ライフタイムに関しても同様

それを正確に反映しようとすると、async関数ではライムタイム省略が行えず、以下のように書く必要が出てくる

code:rust

async fn foo<'ret, 'a: 'ret, 'b: 'ret>(x: &'a i32, y: &'b i32) -> impl Future<Output = i32> + 'ret {

*x + *y

}

これは明らかに煩雑なので避けたい（内部型を選択した大きな理由の一つ）。

6-1-2. 多様な返り値

基本的には、全ての関数はunboxedな値を返すことを推奨している (box化が必要なら呼び出し元で)

これはaysnc関数とは別に要求される機能

(3) ストリームを返すasync関数のサポートが提案されてはいる

ただし、これは返り値がfutureの場合とstreamの場合とで、関数内部の意味論が大幅に変わることを意味する

以上の理由から、多様性(polymorphism)の観点から外部型を採用する大きな論拠はないものと考える。

6-1-3. 学習容易さ／ドキュメントのトレードオフ

利用者の観点からすれば、外部型の方がAPIドキュメントを見た際には直感的

実装者の観点からすれば、内部型の方が「どのような非同期関数を実装すべきか」が分かりやすい

前者の方は、rustdocレベルでカバー可能そう:

具体的に、async関数をAPIドキュメントでどのように扱うか、は未解決の疑問として残っている

6-2. ジェネレータでのマクロではなく組み込み構文にする

長期的に見れば、async関数用に専用構文を用意した方が良いと信じている

その方が書き易いし、利用頻度も十分多いはず

問題は、短期的に「ジェネレータの使用」と「async関数の導入」のどちらの方が安定化までの時間が短くて済むか

=> それを待つより、最小限の組み込みasync/await機能の導入を優先した方が、おそらく安定化は早い

6-3. ジェネレータのみに基づくasync

別のデザインとして「async関数をジェネレータを生成するための構文」として扱うことも考えられる。

このデザインでは、おそらく以下のようにジェネレータを記述する:

code:rust

async fn foo(arg: Arg) -> Return yield Yield

そのため、ジェネレータ関数、async関数、asyncジェネレータ関数、にそれぞれ別の構文を用意した方が上手くいきそう

6-4. "ホットなasync関数"

「"initialization"ステップ」の節で取り上げた挙動をデフォルトにしてしまう案

いろいろと問題がある:

Rustのfutureは、他の言語のそれとは異なり、勝手に処理が進行しない

利用者的にも複雑そう:

6-5. 他の非同期システムではなくasync/awaitを使用する

他の非同期モデルもありえる:

e.g, 汎用化されたエフェクトシステム、モナド＆do記法、グリーンスレッド、スタックフルコルーチン

async/awaitの上により汎用化された層を重ねることも可能かもしれないが、まだ十分な研究はなされていない

2018年の目標を見据えた場合には、async/await構文（多くの言語で利用可能な概念で、既存の非同期I/Oライブラリとも相性が良い）が最も妥当そう

6-6. asyncブロック vs asyncクロージャ

以下のように、両方で同じようなことができるので、片方だけで良いのでは？

code:rust

// almost equivalent

async { ... }

(async || { ... })()

// almost equivalent

async |..| { ... }

|..| async { ... }

確かにそうかもしれないけれど、現状は以下の理由で両方を提供している（安定化前には変わるかも）:

高階async関数は、サービスを構築するために便利かも

7. 先行技術

いろいろな言語（e.g., C#、JavaScript、Python）で、非同期操作を処理するためにasync/await構文が使われている。

asyncおよびawait記法

主に"グリーンスレッド"と呼称される、暗黙的な並行ランタイム（e.g., Go, Erlang）

遅延評価コード上のでモナド変換 (e.g., Haskell）

Rustとはasync/awaitが一番相性が良さそう:

モナドとは異なりownership/borrowingとも上手く共存可能

グリーンスレッドとは異なり、完全にライブラリベースで実現可能

他のasync/await採用の静的型付け言語(e.g., C#)と異なる点は、"内部返り値型"を採用しているところ（理由は上述の通り）。

8. 未解決の疑問

8-1. await式用の最終的な構文

ただ「優先順位」や「区切り文字が必要かどうか」といったことが未解決。

code:rust

await future?

いくつかの対応策が考えられはする:

ユーザはこの見た目に驚きそう

3. 上の優先順位を不便なものと定義する (訳注: ？)

これも他の優先順位と同様に驚きを与えそう

別の解法があるのか、それとも上の中から最もマシなものを選ぶのかは、まだ未解決の疑問。

8-2. 'for await'とストリーム処理

forループで、ストリームをどう処理すべきかも、このRFCでは扱っていない問題。

code:rust

for await value in stream {

println!("{}", value);

}

8-3. ジェネレータとストリーム

将来的には、futureにではなく、streamに評価されるようなasync関数を定義可能にしたくなるかもしれない。

我々は、このユースケースをジェネレータの枠組みで扱うことを提案する。

ジェネレータはイテレータの一種として評価可能で、非同期ジェネレータはストリームの一種と見做すことができる。

以下は、その例（構文はこれから変わるかも）:

code:rust

// Returns an iterator of i32

fn foo(mut x: i32) yield i32 {

while x > 0 {

yield x;

x -= 2;

}

}

// Returns a stream of i32

async fn foo(io: &AsyncRead) yield i32 {

async for line in io.lines() {

yield line.unwrap().parse().unwrap();

}

}

8-4. Unpinを実装したasync関数

これは、async関数に、委譲地点を跨いだ参照を保持することを許可する。

これを有効にするアノテーションに関しては、当面は未指定。

8-5. asyncブロック内での?演算子と制御フロー構成要素

これは失敗する可能性のあるI/Oを扱いやすくするかもしれない:

code:rust

let reader: AsyncRead = ...;

async {

let foo = await!(reader.read_to_end())?;

Ok(foo.parse().unwrap_or(0))

}: impl Future<Output = io::Result<u32>>

code:rust

async {

if true { break "foo" }

}