#非同期処理

TokioはRustの非同期処理を支える定番ランタイムですが、速く動かすための「万能の正解」はありません。今回の元記事は、その前提をかなり率直に書いた実践メモです。遅い原因をTokioそのものに決めつける前に、何を測り、どこを疑い、どこで割り切るべきかを整理しています。読みどころは、抽象論ではなく「現場で本当に効く判断」が並んでいるところでしょう。 元記事は、RustConfのUnconfで交わした議論と、自身の経験をもとにした「fast Tokio applications」の原則をまとめたものだ。著者は、Tokioアプリの性能問題にはハードルの低い決まりごとがほとんどなく、「it depends」が多すぎると認める。そのうえで、まず確認すべきなのは本当に問題があるのか、という点だと強調する。多くの実アプリでは、`.await` に戻るまでの「poll」がAlice Ryhlの勧める 10〜100マイクロ秒よりずっと長いが、それが必ずしもユーザー体験やKPIの悪化に直結するとは限らない。見つけた赤信号を片っ端から直すのではなく、改善したい実際の指標から逆算せよ、という姿勢だ。 性能を

Rustで使える埋め込み型のkey-value storeとして、TurboKVというライブラリがGitHubで公開されています。単に「速いDBです」で終わる話ではなく、非同期API、batchの原子性、range scan、耐久性の切り替え、圧縮、バックグラウンドcompactionまで含めて、かなり実戦的な機能をひと通り揃えているのが目を引きます。Rustで小さく始めたいが、あとから保存方式や一貫性で困りたくない、という人には気になる存在です。今回はそのREADMEを軸に、何を目指したDBなのかと、そこから見える設計の匂いを追います。 TurboKVは「A fast, simple, and embedded key-value store for Rust」と名乗る、非同期の埋め込み型データベースです。READMEでは、atomic batches、ordered range scans、configurable durability、compression、background compaction を備えると説明されています。つまり、単純な `get` / `put` だけの

この記事を読んでまず思ったのは、MCPって派手な機能よりも、地味なメタ情報の積み重ねでかなり賢く見えるようになるんだな、ということだった。ツールを公開する仕組みとして見ると、名前と説明と入力スキーマがあれば最低限は足りそうに見える。でも実際には、クライアントが安心して使えるかどうかは、その先の「このツールは壊すのか、繰り返しても平気か、結果はどんな形で返るのか」といった周辺情報でかなり変わる。そこを丁寧に書けるのが面白い。 特に印象に残ったのは、tool annotations の考え方だ。`readOnlyHint` や `destructiveHint` みたいな値は、機能そのものを増やすわけではない。でも、クライアント側の振る舞いをかなり変えられる。たとえば、確認ダイアログを出すタイミングや、ユーザーに見せる並び順まで変わるかもしれない。ここで大事なのは、著者もはっきり書いているように、これはあくまで hint であって安全装置ではないことだと思う。AI 系の仕組みって、つい「賢く振る舞わせる」話に寄りがちだけど、最終的には認可や検証を別で持たないと危ない。その線引きを曖昧にしな