聞き流しプログラミング言語学習

第46章へようこそ。 今日のテーマは「実行器」です。 第45章で、Futureは自分自身を進める手段を持たないと見ました。 pollを繰り返し呼んで完了まで進める主体は、Futureの外にいる。 今日扱うのは、その外にいる主体が何か、それがどうやって無駄なくpollを繰り返すのか、そしてRustがその主体を標準では持たない設計です。

第45章へようこそ。 今日のテーマは「Future」です。 第44章で、asyncをつけた関数が、中断と再開ができる関数になることを見ました。 asyncをつけた関数を呼ぶと、結果そのものではなく、Futureと呼ばれる値が1つ返ってきます。 今日扱うのは、このFutureが何を表すのか、外からの問い合わせにどう答えるのか、そして中断した地点までの進行をどこに保持するのか、です。

第44章へようこそ。 今日から、非同期処理を扱う一連の章に入ります。 今日のテーマは「非同期入門」です。 これまでの一連の章で見たのは、スレッドによる並行処理でした。 スレッドを使って流れを複数に分け、それぞれの流れを別々に進める方法です。 非同期処理は、並行処理を作るもう1つの道です。 スレッドとは異なる方法で、複数の処理を同時に進行させます。 今日扱うのは、なぜスレッドとは別の道が要るのか、並行と並列と...

第43章へようこそ。 今日のテーマは「デッドロック」です。 ここまで、複数のスレッドが安全に値を共有するための手段を見てきました。 MutexやRwLockは、ロックを取った流れだけに接触を許し、ほかの流れを待たせることで、同時の書き換えを防いだ。 ロックは、待たせることで安全を作る仕組みでした。 しかし、待たせることそのものが、新しい停止を生むことがあります。 複数の流れが、互いに相手の解放を待ち、どちらも進めな...

第42章へようこそ。 今日のテーマは「アトミック」です。 これまでの章で、共有した値を複数のスレッドから安全に書き換える手段として、ロックを見てきました。 MutexやRwLockは、ロックを取った流れだけに値への接触を許し、ほかの流れを待たせる。 ロックを取り、解放するという手順そのものにコストがかかる。 しかし、共有したい値が1つの数や1つの真偽の値のように単純なとき、ロックでひとくくりに囲むのは大げさです。 ロ...

第41章へようこそ。 今日のテーマは「RwLock」です。 前章のミューテックスは、読み取りでも書き換えでも、一度に1つの流れだけにあたいへの接触を許しました。 触れる目的が読み取りであっても、ロックを取った1つの流れが終えるまで、ほかの流れは待つ。 しかし、複数の流れが同じ値をただ読むだけなら、同時に触れても問題は起こりません。 第37章で見たように、読み取りしか起こらないなら、書き換えによる競合は生じないから...

第40章へようこそ。 今日のテーマは「Mutex」です。 前章で、Arcが共有された読み取りのアクセスを与えることを見ました。 複数のスレッドが1つの値を共通の所有者として持ち、それぞれが読める。 ただし、Arcが解決するのは「誰がその値を所有するか」までで、「いつその値を書き換えてよいか」は別の問題でした。 複数のスレッドが同じ値を同時に書き換えれば、書き込みが互いに干渉し、データ競合が起こる。 Mutexは、この「い...

第39章へようこそ。 今日のテーマは「Arc」です。 ここまで、並行処理で値を扱う道は、所有権を移すことでした。 第36章のmoveは、値の所有権を新しいスレッドへ移した。 第38章のチャネルは、値の所有権を流れの間で送って受け渡した。 どちらも、値は常にどこか1つの流れにあり、移ることで次の流れへ渡っていく。 しかし、値を移すのではなく、1つの値を複数のスレッドが同時に保持したい場面があります。 大きな値を、それぞれ...

第38章へようこそ。 今日のテーマは「チャネル」です。 第36章で、moveが値の所有権を新しいスレッドへ移すことを見ました。 あのときの移動は、スレッドを生成する一度きりのものでした。 クロージャに渡した値が、新しいスレッドへ移って、そこで使われる。 チャネルは、この所有権の移動を、スレッドが動いている間ずっと繰り返せるようにする仕組みです。 1つの流れが値を送り出し、別の流れがそれを受け取る。 送り出した側は...

第37章へようこそ。 今日のテーマは、SendとSyncです。 前章で、スレッドに値を渡すときは所有権ごと渡すことを見ました。 moveが、外側の値の所有権をクロージャへ移し、新しいスレッドへ持ち込む。 ただし、すべての値がスレッド境界を越えてよいわけではありません。 ある値をスレッドに渡すと、データ競合という危険が生じる場合がある。 データ競合は、複数の流れが同じ値に同時に触れ、少なくとも一方が書き換えるときに起こ...

第36章へようこそ。 今日から、並行処理を扱う一連の章に入ります。 最初のテーマは「スレッド」です。 スレッドは、プログラムの中で独立して進む実行の流れのことです。 1つのプログラムが複数の流れを同時に持つと、別々の処理が並行して進む。 並行処理は、所有権の規律が新しい場面に置かれる領域です。 これまで所有権は、1つの実行の流れの中で、値がいつ生きていつ解放されるかを決めてきました。 スレッドが増えると、値...

第35章へようこそ。 今日のテーマは「手続き的マクロ」です。 これまでの3章で扱ってきたのは宣言的マクロでした。 macro_rules!の宣言で、パターンと展開の組をルールとして並べる。 入力のトークンがパターンに照らされ、対応する展開が呼び出し位置に差し込まれる。 宣言的マクロには表現の限界があります。 パターンと展開の対応で書ける範囲を超えた変換、たとえば構造体のフィールド名を文字列として取り出して別のコードに...

第34章へようこそ。 今日のテーマは「繰り返しと衛生性」です。 前章で、フラグメント指定子がトークン列の中の特定の位置を捕捉する仕組みを見ました。 式を1つ、識別子を1つ、型を1つ、それぞれ捕捉する。 固定の個数なら、これだけで足りる。 しかしマクロは、任意個のトークンを受け取りたい場面がある。 vecマクロは要素を何個でも受け取って配列を作る。 また、マクロが導入した変数の名前が、呼び出し側の変数の名前と衝突...

第33章へようこそ。 今日のテーマは「マクロのパターン」です。 前章で、マクロ定義はパターンと展開の組であるルールの集まりだと見ました。 呼び出し位置にあるトークン列がパターンに照らされ、一致したルールの展開部分が差し込まれる。 ではパターンの中身はどう書くのか。 ここで中心になるのが、フラグメント指定子と呼ばれる仕組みです。 パターンの中の特定の位置に「ここは式が来る」「ここは識別子が来る」「ここは型が...

第32章へようこそ。 今日のテーマは「宣言的マクロ」です。 これまでの章では、関数を使ってコードの構造を組み立ててきました。 引数を取り、処理を行い、戻り値を返す。 再利用したい処理を関数として切り出す。 ほとんどの抽象は関数で書ける。 しかし関数では書けないものがあります。 要素の個数を決めずに配列を作る、引数の型に応じてフォーマットを組み立てる、ある構造体に対する一連のメソッドをまとめて生成する。 こう...

第31章へようこそ。 今日のテーマはCargoです。 Cargoはビルドツール、パッケージマネージャ、テストランナーを兼ねた、Rustに同梱されているツールです。 コマンドの使い方は調べれば分かるので、本章では扱わない。 扱うのは「Cargoがあることで、Rustの言語側で何が成立しているか」です。 Rustは、コンパイラだけが用意されている言語ではない。 言語仕様、コンパイラ、標準ツール、この3つが一体となって配布されている。 標...

第30章へようこそ。 ここまでの章では、型、所有権、参照、コレクションといった個々の仕組みを扱ってきました。 これらを使ってプログラムを実際に組み立てると、コードは大きくなる。 大きくなったコードを「どう配置し、何を外に見せ、どう参照するか」を決めるのが、モジュールシステムの役割です。 Rustのモジュールシステムには3つの構文があります。 モジュール宣言、public指定、use宣言の3つです。 ソースコード上では、m...

第29章へようこそ。 これまでに扱ったHashMapとHashSetには、共通する性質がありました。 内部はハッシュテーブルで、要素はハッシュ関数によって決まる位置に置かれる。 そのため、要素は挿入順にも整列順にも並ばず、イテレーションの順序は保証されない。 個々の操作はほぼ一定時間で動くが、順序にまつわる操作は構造的に難しい。 順序が必要な場面があります。 キーが範囲で問い合わされる場合。たとえば「ある日付以降のすべ...

第28章へようこそ。 これまでの章では、Vecが連続した領域に要素を並べる構造、HashMapがハッシュ関数でキーと値を対応させる構造として扱ってきました。 この2つはRustでよく使われるコレクションだが、すべての用途を覆えるわけではない。 VecとHashMapには、それぞれの構造から来る向き不向きがある。 Vecは連続配置のため、両端のうち末尾は高速だが、先頭への操作は重い。 HashMapはペアを管理するため、あたいを持たない単純...

第27章へようこそ。 今日のテーマはEntry APIです。 前章ではHashMapの内部構造と基本操作を扱いました。 キーをハッシュ関数に通して整数を得て、その整数からテーブル上の位置を決め、スロットを確認してあたいを取り出す。 挿入、取得、削除、存在確認、いずれも内部ではハッシュ計算とテーブル探索を組み合わせて動きます。 今日扱うのは、この基本操作だけでは無駄が出てしまう典型的な場面と、その無駄を解消するために用意...

第26章へようこそ。 今日のテーマはHashMapです。 前章で扱ったVecは、要素が連続して並んでいる構造でした。 0番、1番、2番というインデックスで要素を取り出す。 インデックスがあらかじめ整数として与えられているなら、即座に要素にアクセスできる。 しかし扱いたい関係が「整数で並べたもの」ではない場合があります。 ユーザー名と設定情報の対応、商品コードと在庫数の対応、英単語とその訳語の対応。 キーになる側が文字列...

第25章へようこそ。 今日のテーマはVecの詳細、その中でも容量と成長です。 Vecはこれまでの章でも何度か登場してきました。 第20章では、Vecがスタックとヒープにまたがる型として、ヘッダ部分にポインタと長さと容量の3つを持つことを確認しました。 要素を追加する基本的な動作は、第4章のイテレータの章で扱っています。 今回はVec自身の動きを内側から扱います。 容量とは何か、長さとどう違うのか。要素を追加するときに何が...

第24章へようこそ。 今日のテーマは「Weakと循環参照」です。 第22章で扱ったRcは、参照カウントが0になった瞬間にヒープ上のあたいを解放する型でした。 誰か1人でも所有者が残っている限り、あたいは生き続ける。 この設計には1つの構造的な弱点があります。 複数のRcが互いに相手を所有し合うとき、カウントがどの所有者から見ても1以上のままで、永久に0に達しない状況が起こり得る。 誰もアクセスできなくなった後も、ヒープ...

第23章へようこそ。 今日のテーマは「RefCellと内部可変性」です。 前章で扱ったRcは、複数の所有者が同じヒープ上の値を共有できる型でした。 しかしRcから取り出せるのは中身への不変参照だけで、可変参照は得られない。 これは「可変参照は同時に1つだけ」という借用規則と整合させるための設計でした。 それでも実用上、共有している値を変更したい状況は頻繁にあります。 ツリー構造で複数のノードが共通の状態を更新する。あ...

第22章へようこそ。 今日のテーマは「Rc」です。 RcはReference Countedの頭文字で、日本語にすれば参照カウントを持つ型ということ。 前章で扱ったBoxは、ヒープ上のあたいに対して所有者が1人だけの型でした。 ヒープを所有する型は所有者が1人というルールに従い、ムーブで所有権が移り、Copyトレイトを持たない。 しかし、複数の場所から同じヒープ上のあたいを所有したい状況があります。 グラフ構造で複数のノードが同じノー...