Repository navigation
transport::stdio() runs every read and write on tokio's blocking pool, which caps stdio throughput #1301
Description
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.
Activity
itsmunzir commentedon Sep 27, 2026
I explored this too, and the design question in the report has a working answer: an additive
stdio_pipes()(the second option you floated) that duplicates the stdio descriptors, verifies both are FIFOs before handing either to Tokio (from_owned_fdsetsO_NONBLOCK, which is shared per open file description, so a partial conversion would leave the blocking fallback in non-blocking mode), and falls back to today's handles for TTYs, files and Windows.stdio()stays untouched, since changing its return type tripsVERSIONING.mdand thepublic-apijob.@igorvieira, you offered to send a PR for this - if you are already on it, just say so and I will close mine; otherwise it is ready for review, with your measurements as the reference in the PR body.
feat(transport): add non-blocking stdio_pipes transport
feat(transport): add non-blocking stdio_pipes transport (#1304)