Tweet
Tweet

Slide 1

Slide 1 text

Rust速習会(3) Webサーバー 2018-11-01 @Wantedlyオフィス (白金台) 原 将己 (@qnighy) 実況用ハッシュタグ: #rust_jp

Slide 2

Slide 2 text

Are We Web Yet? • RustのWeb関係のライブラリの まとめサイト https://www.arewewebyet.org/

Slide 3

Slide 3 text

Webフレームワーク

Slide 4

Slide 4 text

Iron ironframework.io • 安定版コンパイラで動作 / 非同期は未対応 • 昔の覇権 • ちょっと前までメンテナンスが放棄されていたが、メンテナを 募集して復活したっぽい

Slide 5

Slide 5 text

Rocket rocket.rs • 不安定版コンパイラで動作 / 非同期は未対応 • 構文拡張 (独自の #[]) をふんだんに使って書きやすくしてい る • そのため、nightlyの更新ですぐに壊れる • 全体的に作りこまれていて人気っぽい

Slide 6

Slide 6 text

Gotham gotham.rs • 安定版コンパイラで動作 / 非同期対応 • futures/tokioの非同期をうまく使って無難に設計されている • 作りこみは甘い印象 • メンテナ不足のアナウンスが出ていたが、何らかの進展はあっ た模様

Slide 7

Slide 7 text

Actix-Web actix.rs • 安定版コンパイラで動作 / 非同期対応 • 非同期フレームワークの暫定覇権 • futures/tokioに対応しているが、Actixというアクターフレーム ワークが一枚噛んでいる • 比較的ちゃんと作りこまれていてproduction-readyっぽい

Slide 8

Slide 8 text

Tower-Web carllerche/tower-web • 安定版コンパイラで動作 / 非同期対応 • Tokioの作者(のひとり)が書いている期待のフレームワーク

Slide 9

Slide 9 text

Tide (wg-net) • まだ存在しないフレームワーク • RustのNetwork Services Working Groupで計画されているモ ジュラーなフレームワーク • これ自体が流行るかは別として、成果物は各フレームワークに も還元されると思われる • コードだけでなくドキュメントも成果物の一部として規定され ているので、そちらも要注目

Slide 10

Slide 10 text

Rustと非同期I/O

Slide 11

Slide 11 text

そもそも非同期I/Oとは？ • 元々の動機: I/Oは待ち時間が発生するので、できる処理から先 に進める仕組みにしたい 新しい接続リクエストが来たので、これを接続13とする。次のリクエストを受け付けられる状態にしておく。 接続13の最初の35バイトがあるのでパースする。データ不足でパースできなかったのでバッファに溜める。 新しい接続リクエストが来たので、これを接続14とする。次のリクエストを受け付けられる状態にしておく。 接続14の最初の45バイトがあるのでパースする。リクエストの内容がわかったのでデータベースに問い合わせにいく。データベースからはすぐには返 答はこない。 その間に接続13の続きの35バイトが来たのでパースする。まだ十分な情報がないのでバッファに溜める。 また新しい接続リクエストが来たので、これを接続15とする。キューが多すぎるので追加のリクエストはOSに溜めてもらう。 接続13の続きの6バイトが来て、リクエストの内容がわかったので、ファイルを探しに行く。ファイルが見つかったのでヘッダーと最初の20バイトを送 信する。 その間に接続14のためにデータベースにしていた問い合わせが返ってきたので、これをもとにもう一度データベースに問い合わせる。 接続13に追加の35バイトを送信する。 特に何もできないので待機する。 接続13に追加の30バイトを送信する。 接続14のためにデータベースにしていた問い合わせが返ってきたので、レスポンスを作ってヘッダーと最初の20バイトを送信する。 接続13から13バイトが来た。閉じてよいというリクエストなので閉じる。キューが開いたので次のリクエストを受け付けられる状態にしておく。 さっそく新しい接続リクエストが来たので、これを接続16とする。キューが多すぎるので追加のリクエストはOSに溜めてもらう。 ………

Slide 12

Slide 12 text

そもそも非同期I/Oとは？ • 元々の動機: I/Oは待ち時間が発生するので、できる処理から先 に進める仕組みにしたい • ……しかし、実際のプログラムはできるだけ直列的に書きたい。 接続13については パースできるまで読む。76バイト 読み込んでリクエストがわかった。 ファイルを探しにいく。 ファイルが見つかったので合計85 バイト送る。 パースできるまで読む。13バイト 読んでcloseリクエストだったので 閉じる。 接続14については パースできるまで読む。45バイト 読み込んでリクエストがわかった。 データベースに問い合わせる。 その結果をもとにまたデータベー スに問い合わせる。 レスポンスを作って送信する。 …… 接続15については ……

Slide 13

Slide 13 text

並行実行を誰が司るか？ • 選択肢1: 物理的に並列に実行してしまう: マルチCPU/マルチコ ア/ハイパースレッディング • コアの数しかスケールしない • 選択肢1を直接使うことはあまりない CPU #0 接続13を処理している CPU #1 接続14を処理している CPU #3 接続15を処理している

Slide 14

Slide 14 text

並行実行を誰が司るか？ • 選択肢2: OSのスレッド(またはプロセス)管理に任せる • CPUの並列性をいい感じに使ってくれる • そこそこスケールするけど10000並列とかは難しい CPU #0 今は接続13を処理している CPU #1 今は接続14を処理している スレッド 50733 接続13を処理している スレッド 51252 接続14を処理している スレッド 52000 接続15を処理している OS 定期的にどれかのCPUで起動して、CPUを割り当て直す

Slide 15

Slide 15 text

並行実行を誰が司るか？ • 選択肢3: プログラミング言語/ライブラリレベルの抽象化 • スレッド並列性をさらにラップしている • OSスレッドを使うよりもスケールする(らしい) CPU #0 CPU #1 スレッド 50733 スレッド 51252 スレッド 52000 エクゼキュータ 軽量スレッド1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 エクゼキュータ エクゼキュータ

Slide 16

Slide 16 text

並行実行を誰が司るか？ • 選択肢3: プログラミング言語/ライブラリレベルの抽象化 • スレッド並列性をさらにラップしている • OSスレッドを使うよりもスケールする(らしい) CPU #0 CPU #1 スレッド 50733 スレッド 51252 スレッド 52000 エクゼキュータ 軽量スレッド1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 エクゼキュータ エクゼキュータ 高性能といわれるサーバーは、この方法を採用していることが多い

Slide 17

Slide 17 text

非同期I/O戦国時代になった経緯 • 古いRust (～0.11) はグリーンスレッドとlibuvサポートを持っ ていた！ use std::task::spawn; // proc is the closure which will be spawned. spawn(proc() { println!("I'm a new task") }); ちなみにこの頃のRustは組み込みGCサポートやランタイムリフレクションもあったが、それぞれ 0.12と1.0.0-alphaで削除されている

Slide 18

Slide 18 text

非同期I/O戦国時代になった経緯 • Zero cost abstractionに反するなどいくつかの理由からグリー ンスレッドが削除される • 紆余曲折あってFuture(Promise)ベースのライブラリである futures/tokioを推していくことになった • 詳しくはlegokichiさんの明快なスライドを参照 https://qiita.com/legokichi/items/882bcacd12870d087555

Slide 19

Slide 19 text

3つのライブラリ！ futures 汎用の非同期計算ライブラリ mio I/O多重化の 薄い抽象レイヤ tokio 非同期I/Oライブラリ

Slide 20

Slide 20 text

mio: I/O多重化の薄い抽象化

Slide 21

Slide 21 text

mioを説明する前に: I/O多重化とは • 例: 接続27と接続28を並行に処理していて、どちらも読み込み 待ち中とする • OSスレッドを使う場合 スレッド 24887 接続27を処理している スレッド 24890 接続28を処理している OS 接続27から読み込んでください それまでスレッドを止めてください 接続28から読み込んでください それまでスレッドを止めてください

Slide 22

Slide 22 text

mioを説明する前に: I/O多重化とは • をやるためのシステムコールは相場が決まっている 接続27から読み込んでください それまでスレッドを止めてください Man page of READ

Slide 23

Slide 23 text

mioを説明する前に: I/O多重化とは • をやるためのシステムコールは相場が決まっている • RustのAPIもほとんどそのまま 接続27から読み込んでください それまでスレッドを止めてください TcpStream

Slide 24

Slide 24 text

mioを説明する前に: I/O多重化とは • 例: 接続27と接続28を並行に処理していて、どちらも読み込み 待ち中とする • 軽量スレッドを使う場合 スレッド 24887 接続27と接続28を処理している OS 接続27または接続28のうち、早いほうから読み込んでください それまでスレッドを止めてください

Slide 25

Slide 25 text

mioを説明する前に: I/O多重化とは • をやるためのシステムコールはOSによってまちまち 接続27または接続28のうち、早いほうから読み込んでください それまでスレッドを止めてください Man page of EPOLL_WAIT kqueue(2) select(2) という古いシステムコールもあり、 これは多くのPOSIX系OSで共通に使える。

Slide 26

Slide 26 text

mioを説明する前に: epoll(7) の場合 1. 通知を受けたいイベントを全てファイル記述子(整数)として 表す • dup(2), signalfd(2), eventfd(2) などを使う 2. OS側に、イベントの集合を送信する • epoll_create(2), epoll_ctl(2) を使って、逐次的に組み立てる 3. epoll_wait(2)を呼ぶと、指定したイベントのどれかが来るま で待つ。 “(2)” とか “(7)” というのは伝統的なマニュアルの章番号である。Linuxの場合、(1)はコマンド、 (2)はシステムコール、(3)はCライブラリ関数、(7)はまとまった解説になっている。

Slide 27

Slide 27 text

mio – I/O多重化の薄い抽象レイヤ • mio (Metal I/O): epollやkqueueなどのI/O多重化システムコー ルを薄く抽象化するライブラリ • 使い方はepollとほぼ一緒なので、人類が直接使うのには向いて いない 人類が使うための抽象化を別途行う必要がある

Slide 28

Slide 28 text

おまけ: ノンブロッキングI/O • I/O多重化に加えて、以下の操作が必要 • これは O_NONBLOCK などとして比較的標準化されているので、mio のような専用の抽象化は要らない スレッド 24887 接続27と接続28を処理している OS 接続27から読んでください。 すぐに読めないときはブロックせずに戻ってください。

Slide 29

Slide 29 text

おまけ: 真の非同期I/O • OSから能動的な通知を受け取る仕組みもある (aio(7) などを参 照) スレッド 24887 接続27と接続28を処理している OS 接続27から読んでください。 今はすぐ復帰して、あとで完了したら通知してください。

Slide 30

Slide 30 text

おまけ: 真の非同期I/O • OSから能動的な通知を受け取る仕組みもある (aio(7) などを参 照) スレッド 24887 接続27と接続28を処理している OS 読み取り完了しました。(シグナルによる割り込み)

Slide 31

Slide 31 text

futures: 汎用非同期計算

Slide 32

Slide 32 text

Future トレイト • 「時間がかかりそうだったら別のことをやる」をするためのア プローチの一つ • 親が根気強く poll を呼び続けるとやがて答えが返ってくる 親「もしもし、今計算できそうですか (poll を呼ぶ)」 Future「まだですよ (NotReady)」 親「もしもし、今計算できそうですか (poll を呼ぶ)」 Future「まだですよ (NotReady)」 親「もしもし、今計算できそうですか (poll を呼ぶ)」 Future「できました！ (Ready(42))」 Future「もう今後は呼ばないでね」 Futureには先物(未来の価格での取引を保証する金融派生商品)という意味があり、そちらが由来では ないかとも言われている

Slide 33

Slide 33 text

Future トレイト • ざっくり定義すると、こんな感じ pub trait Future { type Output; /// 完了したら `Some`, 途中だったら `None` を返す。 /// `Some` が一度でも返ったら、それ以上呼んではいけない。 fn poll(&mut self) -> Option; } 実はIteratorと同じ。しかし、IteratorはNoneが出るまで呼び続けるのに対して、FutureはSomeが 出るまで呼び続ける。

Slide 34

Slide 34 text

Futureを作ってみよう • フィボナッチ数列をゆっくり計算する例 extern crate futures; // 0.1.25 use futures::prelude::*;

Slide 35

Slide 35 text

Futureを作ってみよう • 計算途中の状態を覚えておく構造体 pub struct Fib { n: u32, // 残りループ回数 a: u32, // 今のフィボナッチ数列の項 b: u32, // 次のフィボナッチ数列の項 }

Slide 36

Slide 36 text

Futureを作ってみよう • 最初の状態を作って返す impl Fib { pub fn new(n: u32) -> Self { Fib { n: n + 1, a: 1, b: 0, } } }

Slide 37

Slide 37 text

Futureを作ってみよう • Fibが最終的に整数を返せるようにしていく impl Future for Fib { type Item = u32; type Error = (); fn poll(&mut self) -> Result, Self::Error> { } }

Slide 38

Slide 38 text

Futureを作ってみよう • 直前の状態を取り出して、計算を1ステップ進める let (a, b) = (self.a, self.b); self.a = b; self.b = a + b; self.n -= 1;

Slide 39

Slide 39 text

Futureを作ってみよう • 終わってたら答えを返す。そうじゃなかったら次回まで待つ if self.n == 0 { Ok(Async::Ready(self.a)) } else { futures::task::current().notify(); Ok(Async::NotReady) }

Slide 40

Slide 40 text

コンビネーター • JavaScriptのPromiseとかと同じで、 コンビネーターで組み立てていく • 組み立てるたびに専用の型がついて いくのがRust流

Slide 41

Slide 41 text

コンビネーターたち(1) future::ok(x) 値を返すだけ future::err(e) エラーを返すだけ future::lazy(|| f()) 非同期関数をあとで実行する futures-0.1, futures-0.2の Future は Result と統合されているので、コンビネーターもエラーが考慮さ れている。ここでは「成功」と「失敗」をあわせて「完了」と呼んでいる。 • 基本ブロック

Slide 42

Slide 42 text

コンビネーターたち(2) fut1.map(|x| f(x)) 成功したら次を実行する (fは普通の関数) fut1.and_then(|x| f(x)) 成功したら次を実行する (fは非同期関数) fut1.map_err(|x| f(x)) 失敗したら次を実行する (fは普通の関数) fut1.or_else(|x| f(x)) 失敗したら次を実行する (fは非同期関数) fut1.from_err(|x| f(x)) 失敗を From で変換する fut1.then(|x| f(x)) 完了したら次を実行する (fは非同期関数) • 続けて何かをする系 futures-0.1, futures-0.2の Future は Result と統合されているので、コンビネーターもエラーが考慮さ れている。ここでは「成功」と「失敗」をあわせて「完了」と呼んでいる。

Slide 43

Slide 43 text

コンビネーターたち(3) fut1.select(fut2) 両方を実行して、どちらか先に完了したほうを使う。 fut1.select2(fut2) 両方を実行して、どちらか先に完了したほうを使う。 違う型を返す Future にも使える future::select_all(iter_fut) 全てを実行して、一番最初に完了したものを使う。 future::select_ok(iter_fut) 全てを実行して、一番最初に成功したものを使う。 • select系 futures-0.1, futures-0.2の Future は Result と統合されているので、コンビネーターもエラーが考慮さ れている。ここでは「成功」と「失敗」をあわせて「完了」と呼んでいる。

Slide 44

Slide 44 text

コンビネーターたち(4) fut1.join(fut2) 両方を実行して、両方の完了を待つ fut1.join3(fut2, fut3) 上に同じ (3個) fut1.join4(fut2, fut3, fut4) 上に同じ (4個) fut1.join5(fut2, fut3, fut4, fut5) 上に同じ (5個) future::join_all(iter_fut) 上に同じ (任意個) • join系 futures-0.1, futures-0.2の Future は Result と統合されているので、コンビネーターもエラーが考慮さ れている。ここでは「成功」と「失敗」をあわせて「完了」と呼んでいる。

Slide 45

Slide 45 text

コンビネーターたち(5) fut1.join(fut2) 両方を実行して、両方の完了を待つ fut1.join3(fut2, fut3) 上に同じ (3個) fut1.join4(fut2, fut3, fut4) 上に同じ (4個) fut1.join5(fut2, fut3, fut4, fut5) 上に同じ (5個) future::join_all(iter_fut) 上に同じ (任意個) • ループ系 futures-0.1, futures-0.2の Future は Result と統合されているので、コンビネーターもエラーが考慮さ れている。ここでは「成功」と「失敗」をあわせて「完了」と呼んでいる。

Slide 46

Slide 46 text

タスク • Future = 非同期Rust世界の関数 • Task = 非同期Rust世界のスレッド • 各タスクは1つのトップレベルFutureを持つ Task1 AndThen Select read read write タスクの 実行状態

Slide 47

Slide 47 text

実行待ちキュー Executor • タスクを抱えて実行する責務を負う Task6 Task3 Task2 Task5 spawn Executor Task6のpollを呼んでいる Task7 再enqueue drop

Slide 48

Slide 48 text

Executor Executor • 複数のワーカースレッドを使う実装もある Worker #1 実行待ちキュー Task6 Task3 Task8 キューに偏りがある ときは融通しあう (work stealing) Worker #2 実行待ちキュー Task9 Task4 Task1

Slide 49

Slide 49 text

実行待ちキュー 通知 • この図の仕組みはちょっと不正確 Task6 Task3 Task2 Task5 spawn Executor Task6のpollを呼んでいる Task7 再enqueue drop

Slide 50

Slide 50 text

休眠中のタスクたち 実行待ちキュー 通知 • NotReadyだったタスクは通知待ちに回される Task15 Task10 Task2 Task3 spawn Executor Task6 drop Task1 Task7 Task12 Task18

Slide 51

Slide 51 text

通知 • 休眠する(NotReadyを返す)前に、通知を受けられるよう準備し ておく必要がある let task = futures::task::current(); some_watcher.register(task); return Ok(Async::NotReady); 現在実行中のタスクのハンドルを取得 ハンドルを誰かに託す 通知を受けるまで休眠する

Slide 52

Slide 52 text

通知 • 休眠する(NotReadyを返す)前に、通知を受けられるよう準備し ておく必要がある let task = futures::task::current(); some_watcher.register(task); return Ok(Async::NotReady); このタスクが再開できる条件を別スレッドが監視している。 再開できそうになったら通知が行われる task.notify(); イベントの種類ごとに通知の責務を受けもつ媒体をドライバーという

Slide 53

Slide 53 text

通知 • 計算負荷が理由で一時的に休眠する場合は、セルフ通知でOK futures::task::current().notify(); return Ok(Async::NotReady); セルフ通知してからNotReadyを返すと、 即座にenqueueされる

Slide 54

Slide 54 text

通知が間違っているとどうなるか • 偽陰性の場合 (再開可能なのに通知されない) • 眠りっぱなしになる • 大変困る • 偽陽性の場合 (意味もなく通知される) • 無駄pollが1回増えるだけ • 困らない • selectで遅いほうのイベントが完了したとき(後の祭り)とかに起こる

Slide 55

Slide 55 text

間違ってブロックするとどうなるか • OSスレッドはCPUのタイマー割り込みで強制的にスレッドを 切り替える仕組みがある (preemptive) が、Rustのタスクには この機能はない (non-preemptive, cooperative) • タスクが間違ってブロックすると、進むはずのタスクまで巻き 添えを食らう。 • スレッドプールベースの場合、何個か同時にブロックしてはじめて発 覚するのでたちが悪い • ブロッキングI/O、Mutex、重い計算などでタスクをブロック しないように気を遣う必要がある

Slide 56

Slide 56 text

futures-cpupool • ブロッキング処理を行うための方法のひとつ Executor 実行待ちキュー Task6 Task3 Task8 Task3は何もせず、 ワーカースレッドの進捗 を問い合わせるだけ Task3の実体 重い計算とかをしてる Futures-cpupool専用 ワーカースレッド

Slide 57

Slide 57 text

tokio: 非同期I/Oライブラリ

Slide 58

Slide 58 text

tokio • mio と futures を組み合わせて、非同期I/Oの統一された枠組 みを提供する

Slide 59

Slide 59 text

tokio tokioランタイム tokio-threadpool executor worker worker worker task task task task task task task task task 各種ドライバー tokio-reactor mio を使ってネットワークを 駆動する tokio-fs ファイルシステム tokio-timer タイマー register notify

Slide 60

Slide 60 text

tokio_threadpool::blocking • ワーカーが1個でも生きていればTokioは回る • Tokioのexecutorに「blocking」フラグを立てることで、その場 でブロッキングを可能にするAPI Executor Worker #1 実行待ちキュー Task6 Task3 Task8 ブロック中なので キューを融通する ブロック中 実行待ちキュー Task9 Task4 ブロック中

Slide 61

Slide 61 text

fahrenheit • futures/tokio のエッセンスを抽出した学習用の実装 • 実質1ファイルに収まっている • futures-rs blogに記事がある • Toykioという名前だったが、あまりの紛らわしさに改名した

Slide 62

Slide 62 text

tokio-core

Slide 63

Slide 63 text

tokio-core • Tokioプロジェクトの古いランタイムライブラリ • tokio-rfcsにデザインドキュメントがある • tokio で書かれたライブラリは tokio-core ランタイムと互 換性がある • tokio-core で書かれたライブラリは tokio ランタイムと互 換性がない • ライブラリが先に新しくなる必要がある！

Slide 64

Slide 64 text

tokio-core • tokio-core はシングルスレッド • tokio に移行するときにはスレッドセーフな実装に切り替える 必要がある • Rc→Arc, RefCell→Mutex, etc. のような書き換えが必要 • ライブラリ作者が頑張る

Slide 65

Slide 65 text

Actix

Slide 66

Slide 66 text

Actix • Rustで書かれたアクターフレームワーク • Tokioと多少の互換性がある • Tokio-reactor を使っているが、tokio-threadpool は使ってい ない (独自executorで動かしている) • したがって、tokio-threadpool の存在を仮定しているライブラ リは動かない可能性がある

Slide 67

Slide 67 text

futures-0.2

Slide 68

Slide 68 text

futures-0.2 (futures-preview-0.2) • futures-0.1 の後継として作られていた • futures-rfcsにデザインドキュメントがある (futures-02, task- context, executors)

Slide 69

Slide 69 text

futures-0.2 の Future • pollが明示的にタスク文脈を受け取るようになった

Slide 70

Slide 70 text

futures-0.2 yank事件 • 諸事情あってfutures-0.2はyankされて別の名前で再公開された (futures-preview 0.2) • yankされると、既存の Cargo.lock を使わない限り解決されなくなる • 特にちゃんとしたアナウンスもなくyankされた • この「yank事件」は結構議論になった • gtk-rs とかが futures-0.2 を使っているらしい

Slide 71

Slide 71 text

async/await

Slide 72

Slide 72 text

Futureのつらみ • Future には現状2つほど「つらみ」がある 1. then/and_then/map によるメソッドチェーンは普通に面倒 2. 借用との相性が悪い

Slide 73

Slide 73 text

futures-await • Rustのasync/awaitの前身 • なんかいい感じにdesugarしてくれるマクロ君 正確に言うとexperimental coroutineという機能に翻訳しているだけなので、 futuresのコンビネーターになっているわけではない

Slide 74

Slide 74 text

futures-awaitの重大な制約 • 借用がawaitをまたぐことができない #[async] fn foo() { let conn = await!(connect()); let result = await!(conn.get(bar)); conn.close(); } こういうのが使えない (普通にFuturesを使っても書けない)

Slide 75

Slide 75 text

futures-awaitの重大な制約 • 借用がawaitをまたぐことができない #[async] fn foo() { let conn = await!(connect()); let (conn, result) = await!(conn.get(bar)); conn.close(); } 所有権を渡して、あとで同じものを返してもらう というインターフェースになる

Slide 76

Slide 76 text

借用とFuture • 「借用している途中のプログラム」を構造体として切り出す • 変数と、その参照がどちらもスタックに乗っていたはず future 変数conn 変数connへの参照

Slide 77

Slide 77 text

借用とFuture • Rustの構造体として書こうとするとこんな感じ struct FooState { conn: Connection, conn_ref: &'self.conn mut Connection, } こういう気持ちは表明できない こういうのを自己参照構造体 (self-referencial struct) あるいは貫入データ構造 (intrusive data structure) という

Slide 78

Slide 78 text

貫入データ構造の問題点 • Rustの値は全てムーブ・リプレースできるが、貫入データ構造 はムーブ・リプレースできない A ARef

Slide 79

Slide 79 text

貫入データ構造の問題点 • Rustの値は全てムーブ・リプレースできるが、貫入データ構造 はムーブ・リプレースできない A ARef

Slide 80

Slide 80 text

?Move の顛末 • Sizedと同様に、デフォルトで有効のトレイト Move を導入す る提案があったが、いくつかの懸念から却下された • これ以上デフォルトトレイトを追加すると混乱が増える • Moveできない型は、関数から返すこともできないから生成することも できない。この部分を解決するにはさらに多くの道具が必要になる

Slide 81

Slide 81 text

Pinned reference (RFC 2349) • ムーブを禁止するのではなく、後からムーブできるような参照 の取り方を禁止してしまえばよいというアイデア • どんなデータも、最初はムーブできる。 • しかし、 Pin<&mut T> という特殊な参照を取ると、その中身 はムーブできない(ムーブしないままDropする必要がある) • これは Pin> というラッパーや pin_mut!() というマクロ によって担保される • ただし、貫入データ構造でない場合は、 Pin<&mut T> から &mut T を復元する余地が残されている。

Slide 82

Slide 82 text

真のasync/await (RFC 2394) • Pin API により、参照を自然に使える • 処理系に組み込みなので、マクロ特有の面倒くささがない async fn foo() { let conn = await!(connect()); let result = await!(conn.get(bar)); conn.close(); } async/awaitは鋭意開発中 futures-0.3 と nightly を組み合わせることで試せる

Slide 83

Slide 83 text

futures-0.3 • async/await対応により、 Future を標準ライブラリ入りさせる 必要が出てきた。 • また、Pinned referenceを使って書き直す必要が出てきた。

Slide 84

Slide 84 text

futures-0.3 pub trait Future { type Output; fn poll(self: Pin<&mut Self>, lw: &LocalWaker) -> Poll; } std::task に移動 Pinned referenceを受け取るようになった。 Resultとの統合が廃止された。 ReadyとNotReadyの2択になった。 Futures-0.2 に導入されていたcontextが 単純化された。 通知用のハンドルだけを持ち回す。

Slide 85

Slide 85 text

futures-0.3 • futures-0.3は(現状)不安定版のコンパイラに強く依存している。 • しかし、今後はfutures-0.2ではなくfutures-0.3が開発される。 • Tokioのfutures-0.2移行も白紙に戻ってしまった。 • (おそらく)そういう事情から、futures-0.2/futures-0.3はプレ ビュー版としての立場を明確にしたいという動きがあり、それ がyank事件につながった？

Slide 86

Slide 86 text

Futures/tokioまとめ • 複雑で面倒くさい事情がある • 最終的にasync/awaitに収斂していって皆幸せになる……はず

Slide 87

Slide 87 text

ハンズオンの準備

Slide 88

Slide 88 text

Rustを最新にしておく $ rustup update

Slide 89

Slide 89 text

Dieselの準備 • MySQLとPostgreSQLのdevライブラリを入れておく。例: $ sudo apt install libpq-dev libmysqlclient-dev $ brew install postgresql mysql dieselがデフォルトで両方を要求するので、両方入れておく。 必要なほうを入れておいて、あとでdieselのオプションを指定するのでもOK

Slide 90

Slide 90 text

Dieselの準備 • diesel-cliを入れる $ cargo install diesel_cli ビルドに少し時間がかかるので、次に進んでおくとよい

Slide 91

Slide 91 text

Dieselの準備 • diesel-cliを入れる $ cargo install diesel_cli PostgreSQLサポートのみで入れるには以下のようにする: $ cargo install diesel_cli --no-default-features --features postgres

Slide 92

Slide 92 text

データベースの作成 $ createdb todoapp うまいURL

Slide 93

Slide 93 text

データベースの接続確認 $ psql postgres:///todoapp psql (10.5 (Ubuntu 10.5-0ubuntu0.18.04)) Type "help" for help. todoapp=# ¥q うまいURL

Slide 94

Slide 94 text

データベースの接続確認 $ psql postgres:///todoapp psql (10.5 (Ubuntu 10.5-0ubuntu0.18.04)) Type "help" for help. todoapp=# ¥q 以下のような亜種が有効かも: postgres://localhost/todoapp postgres://username:@localhost/todoapp postgres://postgres:@localhost/todoapp postgres://username:password@localhost/todoapp postgres://postgres:password@localhost/todoapp

Slide 95

Slide 95 text

サーバーを書き始めよう

Slide 96

Slide 96 text

プロジェクトを立てる $ cargo new todo-app $ cd todo-app

Slide 97

Slide 97 text

プロジェクトを立てる • Cargo.tomlに依存関係を追加 [dependencies] log = "0.4.6" env_logger = "0.5.13" dotenv = "0.13.0" serde = "1.0.80" serde_derive = "1.0.80" serde_json = "1.0.32" actix-web = "0.7.13"

Slide 98

Slide 98 text

プロジェクトを立てる • Cargo.tomlに依存関係を追加 [dependencies] log = "0.4.6" env_logger = "0.5.13" dotenv = "0.13.0" serde = "1.0.80" serde_derive = "1.0.80" serde_json = "1.0.32" actix-web = "0.7.13" 依存関係を変えたらとりあえず しておくと便利 $ cargo build

Slide 99

Slide 99 text

プロジェクトを立てる • extern crateしておく #[macro_use] extern crate log; extern crate env_logger; extern crate dotenv; extern crate serde; #[macro_use] extern crate serde_derive; extern crate serde_json; extern crate actix_web; log, serde_derive由来のマクロを使うので明示 最新安定版の1.30.0からは通常のuseで マクロをインポートすることができる。 また1.31.0からはデフォルトでRust 2018が 有効になるため、extern crateは不要になる。

Slide 100

Slide 100 text

ロギングの準備 fn main() { dotenv::dotenv().ok(); env_logger::init(); info!("Hello, world!"); } dotenvは失敗してもいいので .ok() でOptionに変換することで 無視している

Slide 101

Slide 101 text

ロギングの準備 • .env というファイルを作成 RUST_LOG=todo_app=debug,actix=info ライブラリごと・モジュールごとに ログレベルを指定できる。 このファイルは dotenvライブラリを使って 環境変数として読み込まれる

Slide 102

Slide 102 text

ロギングの準備 • ロギングできていることを確認 $ cargo run INFO 2018-11-01T06:33:40Z: todo_app: Hello, world!

Slide 103

Slide 103 text

サーバーを起動する use actix_web::{server, App}; fn main() { env_logger::init(); debug!("Launching an app..."); server::new(|| App::new()).bind("[::]:8080").unwrap().run(); } イントラネットに公開したくない場合は "localhost:8080"

Slide 104

Slide 104 text

サーバーを起動する • これでサーバーは立ち上がる $ cargo run DEBUG 2018-11-01T06:44:05Z: todo_app: Launching an app... INFO 2018-11-01T06:44:05Z: actix_net::server::server: Starting 2 workers INFO 2018-11-01T06:44:05Z: actix_net::server::server: Starting server on [::]:8080 ブラウザからアクセスすると404が返ってくるはず

Slide 105

Slide 105 text

エンドポイントを追加する use actix_web::{http, Path, Responder}; fn ping(_: Path<()>) -> impl Responder { "pong" } 既存の行にいい感じに追加してください

Slide 106

Slide 106 text

エンドポイントを追加する server::new(|| App::new() .route("/ping", http::Method::GET, ping) ) ここを増やす

Slide 107

Slide 107 text

サーバーを再起動する $ RUST_LOG=todo_app=debug,actix=info cargo run DEBUG 2018-11-01T06:44:05Z: todo_app: Launching an app... INFO 2018-11-01T06:44:05Z: actix_net::server::server: Starting 2 workers INFO 2018-11-01T06:44:05Z: actix_net::server::server: Starting server on [::]:8080 /pingにアクセスするとpongが返ってくる

Slide 108

Slide 108 text

テンプレート

Slide 109

Slide 109 text

Askamaを使う • Cargo.tomlに依存関係を追加 [dependencies] askama = { version = "0.7.2", features = ["with-actix-web"] } [build-dependencies] askama = "0.7.2" 両方必要

Slide 110

Slide 110 text

Askamaを使う • build.rs というファイルをプロジェクト直下に作成する extern crate askama; fn main() { askama::rerun_if_templates_changed(); } build.rs はコンパイル時に実行される。 そのため以下の特徴がある • クロスコンパイル時もホストアーキテクチャにコンパイルされる • 依存関係が区別される。 ([build-dependencies])

Slide 111

Slide 111 text

テンプレートを書く • templates/base.html {% block title %} default title {% endblock %} {% block content %}

default content

{% endblock %}

Slide 112

Slide 112 text

テンプレートを書く • templates/index.html {% extends "base.html" %} {% block title %}Top{% endblock %} {% block content %}

Top

Hello, Askama!

{% endblock %}

Slide 113

Slide 113 text

テンプレートを使う #[macro_use] extern crate askama; use askama::Template; #[derive(Debug, Template)] #[template(path = "index.html")] struct IndexTemplate; テンプレートの描画に必要な引数は、この構造体に詰める 最新安定版の1.30.0からはuse askama::Templateで Templateのderive macroもインポートされるので、 #[macro_use] は不要になる

Slide 114

Slide 114 text

テンプレートを使う fn index(_: Path<()>) -> impl Responder { IndexTemplate } … App::new() .route("/", http::Method::GET, index) .route("/ping", http::Method::GET, ping) 今のところテンプレート引数はないので、こうなる ここまで書いて実行すると描画される

Slide 115

Slide 115 text

静的ファイル

Slide 116

Slide 116 text

静的ファイルをサーブする use actix_web::fs::StaticFiles; … App::new() .handler("/static", StaticFiles::new("./static").unwrap()) .route("/", http::Method::GET, index) .route("/ping", http::Method::GET, ping) ./static を / からサーブしたりするのはもう少し工夫が必要そう。 複数個の StaticFiles を作ると無駄スレッドが大量にできるので、 こちらも工夫が必要

Slide 117

Slide 117 text

静的ファイルをサーブする • ./static/style.css とかを書いてみる body { background-color: #888888; }

Slide 118

Slide 118 text

静的ファイルをサーブする • ./templates/base.html に行を足してみる

Slide 119

Slide 119 text

データベース

Slide 120

Slide 120 text

データベース • Cargo.tomlに依存関係を追加 [dependencies] chrono = "0.4.6" diesel = { version = "1.3.3", features = ["postgres"] } cargo build を流しつつ次に進もう

Slide 121

Slide 121 text

データベース • .env に以下を追加 (psqlで繋がるURLを指定する) DATABASE_URL=postgres:///todoapp

Slide 122

Slide 122 text

データベース $ diesel setup

Slide 123

Slide 123 text

データベース $ diesel migration generate create_todos

Slide 124

Slide 124 text

データベース • up.sql ができているので以下のようにする CREATE TABLE todos ( id BIGSERIAL PRIMARY KEY, created_at TIMESTAMP NOT NULL, updated_at TIMESTAMP NOT NULL, content VARCHAR NOT NULL )

Slide 125

Slide 125 text

データベース • down.sql ができているので以下のようにする DROP TABLE todos

Slide 126

Slide 126 text

データベース • upを実行する $ diesel migration run

Slide 127

Slide 127 text

データベース • downの動きも見たいので、downしてupしてみる $ diesel migration redo

Slide 128

Slide 128 text

データベース • スキーマを読み込む #[macro_use] extern crate diesel; mod schema; src/schema.rs が自動生成されている

Slide 129

Slide 129 text

時間切れ…… • 残りは上手くいったらライブコーディングします！