{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreighe562xxj7nhf27gq6yljlqz4p44hqkvjno3usrb4ml645nqr7oe",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mjbdsjjpzbs2"
  },
  "path": "/t/going-from-asyncwrite-to-asyncread/24130#post_5",
  "publishedAt": "2026-04-11T12:02:07.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "Does the FutureLock bug really apply here? If the Stream is dropped, so is the Future and any potential Mutexes it curently holds… I think it’s just a problem if we have clients which stops polling new data…\n\nBut if a Http-Client could pause the polling of our Abstraction’s AsyncRead, it would be a problem in all async code, which is using mutexes… This would be a weakness in the WebServer implementation\n\nIf the user is using stuff like select! within our future or outside (using our AsyncRead), he has to know what he’s doing until we get undropable types or a similar language solution. I don’t see, how this abstraction makes things worse. If the user holds a Mutex in the inner future from start to end, this might be a actual requirement.\n\nOr do you mean/think, that it’s not fundamentally wrong to poll only futures from other AsyncRead if a poll_read returns ready, without getting the next Future of a AsyncRead and polling it together with the rest?",
  "title": "Going from AsyncWrite to AsyncRead"
}