TUI実装と非同期実装パターン

最近自分用のtmux session managerでtmux-deckというCLIを作っている。

GitHub - takeshiD/tmux-deck: tmux session manager and realtime previewer

tmux session manager and realtime previewer. Contribute to takeshiD/tmux-deck development by creating an account on GitHub.

GitHub

たたき台レベルをClaudeCodeに作らせてパフォーマンスチューニングを自分で行っている。その中で非同期処理のパターンを勉強する必要が出てきたので学んでいる。

きっかけはこのCLIの仕組みで、TUIクレートにratatuiを使っているのだが

• UIレンダリング
• キーイベント
• 他の処理(tmux capture-paneなど) ナイーブに書くとこれらが全て同期的に行われる。ClaudeCodeに特別指示していなかったので同期的なコードが実装された。

自分の知識不足なのでしょうがないので、この点は自分で実装することにした。ちょっとした修正程度かと思いきやRustで複数の処理を並行して動かそうとすると所有権の問題が出てきて大変煩わしい。具体的にはArcとRwLockで実装したのだが、いくつかテクニカルなことをしなければクリア出来ない点が発生してしまいあまり良い実装では無いと感じた。

このような需要は世の中にあるはずで、良い実装パターンが無いか探した結果以下の本に帰着した。

Async Rust

ネットワークアプリケーションの複雑化により、数千から数万のネットワーク処理を並行して処理することが求められるようになりました。OSが提供するスレッドでも並行処理は実装可能ですが、オーバーヘッドが大きいためこの規模の並行性を実現することは困難です。このため、プロセス内部で複数のタスクをスケジューリングすることで並行性を実現する非同期機構の採用が、さまざまな言語で進んでいます。Rustのasync/awaitによる非同期機構はその1つで、async/awaitによる簡潔でわかりやすい記述をコンパイラが状態遷移マシンに書き換えることで、スタックを使用しない低コストな非同期実行を実現しています。本書は、async/await機構の実装を通じてその仕組みを理解し、代表的な活用方法をマスターできる構成となっています。

www.oreilly.co.jp

読み進めるとActor modelというものが出てくる。非同期処理、ないしはRustでの並行処理はActor modelを基礎にすると筋が良さそうだ。

Actor modelはマイクロアーキテクチャを一つの実装の中で行なうような思想で、1スレッドを1システムとして扱うような思想と理解した。

ratatuiでも相性は良さそうで試してみようと思う。

一方で別のアーキテクチャでElmやFluxというフロントエンドでよく見かけるアーキテクチャもratatuiのドキュメントで目にする。

悩んでいるがこれらのアーキテクチャパターンを試してみてどのパターンが筋が良いのか、それぞれの特徴はなにか掴んでいきたい。

なんとも締まりは悪いが最近の学びはこのようなこととなる。