title: What is the best approach to encapsulate blocking I/O in future-rs?
body: <p>I read the <a href="https://tokio.rs/docs/getting-started/tokio/" rel="noreferrer">tokio documentation</a> and I wonder what is the best approach for encapsulating costly synchronous I/O in a future.</p>
  
  <p>With the reactor framework, we get the advantage of a green threading model: a few OS threads handle a lot of concurrent tasks through an executor.</p>
  
  <p>The future model of tokio is demand driven, which means the future itself will poll its internal state to provide informations about its completion; allowing backpressure and cancellation capabilities. As far as I understand, the polling phase of the future must be non-blocking to work well.</p>
  
  <p>The I/O I want to encapsulate can be seen as a long atomic and costly operation. Ideally, an independent task would perform the I/O and the associated future would poll the I/O thread for the completion status.</p>
  
  <p>The two only options I see are:</p>
  
  <ul>
  <li>Include the blocking I/O in the <code>poll</code> function of the future.</li>
  <li>spawn an OS thread to perform the I/O and use the future mechanism to poll its state, as <a href="https://tokio.rs/docs/going-deeper/synchronization/" rel="noreferrer">shown in the documentation</a></li>
  </ul>
  
  <p>As I understand it, neither solution is optimal and don't get the full advantage of the green-threading model (first is not advised in documentation and second don't pass through the executor provided by reactor framework). Is there another solution?</p>