mioを直接叩く代わりにtokioを用いることでプログラマが何から解放されるのか
mars2nico2年前このメモを書いた
ここらへんがあいまいとした下記の事柄について調べる。
- tokioによってmioを直接叩くことから何が解放されたのか
このスクラップの範囲
- mio->tokioの文脈
- futureについて（アバウト）
このメモのスコープ外
- futexの周り
- sendtoの後にepoll_waitが2回呼ばれている理由
- Dtraceとstraceを併用してプラットフォーム間差異を調べる
下記も理解があいまいだがシステムコールやプラットフォーム間差異については今はモチベーションがないので調べない
mars2nicoRuntimeモジュールのドキュメントを読んでいなかっただけだった。
mioの代わりにtokioを使うことでイベント駆動型プログラミングのコア部分の実装から解放されて、イベントハンドラのコーディングに集中できることが分かった。
mars2nicofutureについて（アバウト）
うまく言語化できないがRustのFutureやJavascriptのPromiseについては
- 考えたくないことを匿名にする。
- 多くを機械の推論に頼る。
ことで、ビジネスロジックのコーディングに集中できることが注目されている理由だと感じた。
mars2nico感想
Tokioに興味をもったそもそもの理由はRustのFutureやJavascriptのPromiseについてで、
Promiseについて興味をもったそもそもの理由がVueのリアクティビティーシステムで、
Vueのリアクティビティーシステムに興味をもったそもそもの理由がUniRxだった。
これまで調べてきたことを通して考えると、明確にロジカルに組み立ててはいないが、リアクティビティーシステム及びそれを実装するRxとは特定のドメインでよく使われる機構であり、そのシンタックスがasync構文なんだなと思った。それでかつasync構文を使うにはRustのFutureやJavascriptのPromiseの機能について理解が必要と感じた。
また、次の理解がまだあいまいだなと感じた。
- Rxがフォーカスする特定のドメインとは何か
- 各言語（私の場合はC#とJavascriptあとできたらRustに注目）におけるFutureとPromiseの実装
mars2nico感想 その2
ここはAIに要約してもらった。展開して元の文章を見る。
元の文章
まだはっきりとはしていないが複数のサイトや記事を確認して、よくある案内としてはIO-boundならasync/await。CPU-boundならOS(カーネル)スレッドを使えばよいというのが見受けられる。
リアクティビティーシステムが取り上げられるのはフロントエンドを書くときなので、ユーザ入力待ちや通信待ちが発生するようなケースであること（IO-boundであること）は比較的想像ができる。
なので、Rxがフォーカスする特定のドメインとは「IO-boundな状況において生産性高くコーディングできる方法」だろうと感じた。
AIログ
せっかくなので、CopilotとGeminiに同じプロンプトで手伝ってもらった。
Copilotの場合
Copilot 1.25032.167.0
起承結の順で要約してください。
起: まだ明確ではないが、複数のサイトや記事を確認したところ、IO-boundならasync/await、CPU-boundならOS（カーネル）スレッドを使うのが一般的な案内であることが分かった。
承: リアクティビティーシステムは主にフロントエンドで活用され、ユーザ入力待ちや通信待ちが発生するケース（IO-bound）の想定がしやすい。
結: そのため、Rxがフォーカスするドメインは、「IO-boundな状況において生産性高くコーディングできる方法」なのではないかと考えた。
この構成なら明快に論理展開が伝わるはず。どうかな。
結論は正しいと思いますか。
はい、結論は論理的に適切だと思います。
Rx（Reactive Extensions）がIO-boundな状況での生産性向上を目的としているという考えは、リアクティブプログラミングの一般的な用途と一致しています。特にユーザ入力待ちや通信待ちが発生するシナリオでは、非同期処理やストリームの管理が重要になるため、Rxの設計思想と合致していると言えます。
ただ、さらなる精度を求めるなら「Rxの目的はIO-boundな状況において最適なコーディング手法を提供すること」といった言い回しも考えられるかもしれません。どの程度厳密に表現するかは、対象読者と文脈次第ですね。
この視点、どう思いますか？
Geminiの場合
Gemini 2.0-Flash
起承結の順で要約してください。
承知いたしました。起承結の順でこの文章を要約します。
起：複数の情報源によると、処理の内容によってasync/await（IO-bound）とOSスレッド（CPU-bound）の使い分けが一般的なようだ。
承：フロントエンドにおけるリアクティビティーシステムは、ユーザー入力や通信待ちといったIO-boundな状況で重要となる。
結：したがって、Rx（Reactive Extensions）が主に焦点を当てるのは、「IO-boundな状況において効率的に開発を進めるための方法」であると考えられる。
結論は正しいと思いますか。
結論は概ね正しいと考えられます。
Rx（Reactive Extensions）が提供するリアクティブプログラミングのパラダイムは、非同期処理やイベントストリームを扱いやすくすることに主眼が置かれています。これらの多くは、ネットワークリクエスト、ユーザー入力、ファイルI/Oなど、IO-boundな処理に該当します。
Rxの持つ以下の特徴が、IO-boundな状況での生産性向上に貢献します。
- 非同期処理の抽象化: Observableという概念を用いて、非同期処理を同期処理のように扱えるようにします。
- イベントストリームの統合: 様々なイベントソースを統一的なストリームとして扱えます。
- 豊富な演算子: フィルタリング、変換、結合など、ストリームを操作するための強力な演算子が多数用意されています。
- エラーハンドリング: 非同期処理で発生するエラーを適切に処理するための仕組みを提供します。
もちろん、RxがCPU-boundな処理に全く向かないわけではありません。演算子によってはCPUを消費するものもありますし、非同期処理のパイプラインの中でCPU-boundな処理を組み込むことも可能です。
しかし、Rxの本質的な強みは、非同期的なイベントの流れを効率的に管理し、複雑な非同期処理を宣言的に記述できる点にあり、これはまさにIO-boundな状況でその恩恵を最大限に発揮します。
したがって、「Rxがフォーカスする特定のドメインとは「IO-boundな状況において生産性高くコーディングできる方法」だろうと感じた」という結論は、Rxの主要な目的と利点を捉えており、妥当性の高いものと言えるでしょう。
複数の情報源によると、処理の内容によってasync/await（IO-bound）とOSスレッド（CPU-bound）の使い分けが一般的なようだ。
フロントエンドにおけるリアクティビティーシステムは、ユーザー入力や通信待ちといったIO-boundな状況で重要となる。
したがって、Rx（Reactive Extensions）が主に焦点を当てるのは、「IO-boundな状況において効率的に開発を進めるための方法」であると考えられる。また、あるアプリケーションが抱えるパフォーマンス問題についてIO-boundかどうかをプロファイリングする方法の理解が必要なことが分かった。
わからないこと
なので、１つ前の「感想」に記載した点を下記の通り修正する。
- 並列処理のプロファイラを使って分かること
- 各言語（私の場合はC#とJavascriptあとできたらRustに注目）におけるFutureとPromiseの実装