transport::stdio() runs every read and write on tokio's blocking pool, which caps stdio throughput
メンテナーはふだん 3 日以内に返信
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 58/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- rust
調査の方向性
Start by locating the implementation of rmcp::transport::stdio() and review how its Tokio stdin and stdout handles perform reads and writes. Run the Carmy comparison harness linked in the issue, then verify that a pipe-based path improves throughput while retaining the current fallback for TTYs, files, and Windows.
索引モデルが issue の本文から書いたものです。
説明
rmcp::transport::stdio() returns (tokio::io::Stdin, tokio::io::Stdout). In tokio, each read
from and write to these handles goes through the blocking thread pool, so every message pays a
cross-thread hand-off. Under concurrent tools/call, a profile of an rmcp stdio server
shows most of its time in __psynch_mutexwait / cvsignal, not in actual work.
When the server's stdin and stdout are pipes, which is how MCP clients launch servers,
readiness-driven pipes avoid the hand-off:
use std::os::fd::AsFd;
use tokio::net::unix::pipe;
let stdin = std::io::stdin().as_fd().try_clone_to_owned()?;
let stdout = std::io::stdout().as_fd().try_clone_to_owned()?;
// Both fail unless the descriptors are FIFOs; fall back to transport::stdio() then.
let transport = (pipe::Receiver::from_owned_fd(stdin)?, pipe::Sender::from_owned_fd(stdout)?);
The fallback keeps TTYs, files and Windows on the current path.
Numbers: the same trivial tool, 32 concurrent callers over one stdio connection, on an
Apple M3 Pro. Reproducible harness:
https://github.com/igorvieira/Carmy/tree/main/benches/compare
| server | throughput |
|---|---|
rmcp 3.4 with transport::stdio() |
~41k req/s |
the same rmcp server over tokio::net::unix::pipe |
~86k req/s |
@modelcontextprotocol/sdk (TypeScript), for reference |
~73k req/s |
Would a pipe-based fast path in transport::stdio(), or a separate stdio_pipes()
constructor, be welcome? I'm happy to send a PR.
- 主要言語
- Rust
- スター
- 4k
- フォーク
- 654
- 平均マージ
- 4日 2時間
- マージ済み PR（30日）
- 40
環境構築
このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
modelcontextprotocol/rust-sdk のほかの issue
-
P3 question T-documentation T-enhancement
難易度 1/5 1時間未満 初心者へのやさしさ 86/100
modelcontextprotocol/rust-sdk#1155 ·
メンテナーはふだん 3 日以内に返信
-
bug P1 ready for work T-transport
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
modelcontextprotocol/rust-sdk#1325 ·
メンテナーはふだん 3 日以内に返信
-
streamable-http server: client responses to server-initiated requests (sampling/elicitation/roots) are 202-accepted and silently discarded under the 2026-07-28 protocol — the pending request hangs forever対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープンbug P1 ready for work T-transport
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
modelcontextprotocol/rust-sdk#1321 ·
メンテナーはふだん 3 日以内に返信
-
Bound pre-lifecycle bootstrap attempts in server initialization対応中かも @DaleSeo が 4 日前に担当しました。 オープンenhancement P2 T-service T-transport
modelcontextprotocol/rust-sdk#1315 · 担当者 1 名 ·
メンテナーはふだん 3 日以内に返信
-
ProgressDispatcher: a slow progress subscriber blocks subscribe() and delivery for other tokensオープンbug P1 ready for work T-handler
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
modelcontextprotocol/rust-sdk#1312 ·
メンテナーはふだん 3 日以内に返信
modelcontextprotocol/rust-sdk の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
joshstevens19/rindexer#483 ·
メンテナーはふだん 1 日以内に返信
-
VX_PRINT_DROPS prints each drop point twice on the default code generator, the second time at line 0オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
CommunityToolkit/Aspire#2231 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100