https://speakerdeck.com/sanposhiho/goniokeruakutamoderufalseshi-xian-ni-xiang-ketaraiburarifalseshe-ji-toshi-zhuang

Transcript

  1. → あるプロセスがクラッシュしても他のプロセスに影響しにくい • ホットスワップ: プログラム全体の再起動をせずにプロセスを入れ替える 10

    10 Erlang アクターモデルを採用 • アクター = ErlangVM上の一つのプロセス • プロセス同士は完全に分離 (メモリ空間など)

  2. 20

    20 ライブラリの設計デザイン 1. ユーザーがメソッドを定義する 2. アクターの構造体が生成され、その構造体はユーザーが定義したメソッドを全ても つ 3. アクターの構造体に対して、メソッド呼び出しを行うと、 内部的にはアクター的な振る舞いをしており、非同期に処理が行われる。

  3. • google/wire: 依存性注入(DI)のためのフレームワーク 21

    21 Go におけるコード生成 Goではコード生成により、ユーザーに機能を提供するライブラリがいくつか存在 • golang/mock: モックのためのフレームワーク • ent/ent: エンティティフレームワーク(ORM)

  4. 22

    22 ライブラリの設計デザイン 1. ユーザーがメソッドを定義する 2. アクターの構造体が生成され、その構造体はユーザーが定義したメソッドを全ても つ 3. アクターの構造体に対して、メソッド呼び出しを行うと、 内部的にはアクター的な振る舞いをしており、非同期に処理が行われる。

  5. 発生する。 30

    30 簡単な使用例 3. Futureから結果を受け取る 受け取ったFutureのGetメソッドを呼び出すことで、処理の結果を受け取ることができ る。 - この時点で処理が終わっている場合は、即時結果を受け取れる。 - この時点で処理が終わっていない場合は、アクターが結果を処理するまで待ちが

  6. 数の処理を実行しない。) 3. 処理結果をFutureに送信する。 32

    32 細かな内部実装を軽く紹介 おさらい: アクターのメソッドが呼ばれると、アクターは… 1. 同期的には仮の値であるFutureを返す。 2. 非同期に処理を行う。 - (複数のスレッドから同時に複数のメソッドを呼ばれていた場合でも同時に複

  7. 内部の処理を実行 結果をFutureに送信 ↓Futureを作成。 Futureを返却 37

    37 この go func (){ ... }で囲われた部分が 軽量スレッド内の処理 ロック。軽量スレッド終了時にロックの解除。

### [38 アクターリエントランシー Swiftを参考にリエントランシーと呼ばれる仕組みを導入。 アクターの処理の中で、Futureで他のアクターの処理の終了を待っている間(= future.Getで待ちが発生している間)は、そのアクターは他の処理を行うことができる。 → これにより、デッドロックを防いでいる。 38](<https://files.speakerdeck.com/presentations/d0e6b4c82986476f9c81524fceacff05/slide_37.jpg>)

  1. ジを処理できない。 すると、アクターBの処理は永遠に終わらないのでデッドロック 39

    39 アクターリエントランシー リエントランシー無しだと、デッドロックが起こってしまう例: 1. アクターAとアクターBが存在し、アクターAがアクターBにメッセージを送り、結果を まつ。 2. アクターBはそのメッセージの処理中に、アクターAにメッセージを送り、結果をま つ。 アクターAは1でアクターBのメッセージを待っているため、アクターBが2で送ったメッセー

  2. Goのエコシステムを全 てそのまま使用できる。 - Futureへの処理結果の送信の箇所を、ジェネリクスで実現しているため、メッセー ジングが型安全である。 - 他のライブラリはメッセージングに型がつかない。例えば、誤った型のメッセージを送信した場合 に、開発者は気がつくことができない。 40

### [40 既存のGoのアクターモデルライブラリとの比較 protoactor-go、ergoなどが存在 - Swiftのアクターようなデザインのものは存在しないので、デザインが他と大きく異 なる。 - オブジェクト指向に慣れている開発者がそのままの感覚で使用できる。 - interfaceやモックなど、既存のオブジェクト指向プログラミングを前提とした](<https://files.speakerdeck.com/presentations/d0e6b4c82986476f9c81524fceacff05/slide_39.jpg>)

### [43 Non-reentrant アクター リエントランシーが有効でないアクターを生成できるオプションの作成。 Non-reentrantなアクターは前述のデッドロックを起こす可能性があるが、 それを動的に発見する機能を同時に提供することが、技術的に実装可能である。 (静的に発見することは難しい。) 43](<https://files.speakerdeck.com/presentations/d0e6b4c82986476f9c81524fceacff05/slide_42.jpg>)
  1. 47
### [47 宣言的な管理による、他のホストでのアクターの起動 他のホストのアクターを同時に管理できると、分散システムが構築しやすい。 宣言的に管理しておくことで、「host Bでactor Aを起動する」というふうに登録すること により、host Bで起動しているアクターを管理するコンポーネント(前述) がactorAを起 動してくれる。](<https://files.speakerdeck.com/presentations/d0e6b4c82986476f9c81524fceacff05/slide_46.jpg>)