{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigwmluua5yustper2yb7oonbuaq6xzk6yflvhim2nwvldjjcej6mi",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mjbkjxshmmz2"
  },
  "path": "/t/going-from-asyncwrite-to-asyncread/24130#post_3",
  "publishedAt": "2026-04-11T07:57:49.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "issue"
  ],
  "textContent": "I've seen and used `ReaderStream`sucessfully together with axum. Unfortunately, the tokio-dependency is a showstopper since the code is used in the Browser too for uploads... But `AsyncRead`→`Stream<Item=Bytes>` is rather simple and was discussed in futures-util already (issue)\n\nI have not seen a helper in tokio-util, which allows writing to a AsyncWrite to get a AsyncRead... I need that to write to AsyncZipWriter.... In the first attempt, i used ReaderStream with a tokio free alternative of tokio_util::io::simplex and spawned a background task to fill the Writer... But this involves spawning a Task, using a Queue and its a mess, to correctly handle io-Errors in the spawned Task correctly… Use of `?` there is almost certainly wrong, as we need to Kill the connection, so the receiver knows, that things went south and doesn’t just get EOF…\n\nWith the proposed util, it could be implemented runtime independent, without allocations and even without locking or Atomics, which should enable aggressive compiler optimizations… Such `encoders` (what they basically are) could even be used in no-std/no-alloc environments\n\nThe cool thing about this abstraction is, that polling the stream also drives the future if progress should be made…",
  "title": "Going from AsyncWrite to AsyncRead"
}