question about blocking action?

[zhuxiujia]

If I want to run a blocking action, do I need to manually differentiate? Can you automatically To deal with?

async fn read_to_string(path: impl AsRef<Path>) -> io::Result<String> {
task::spawn_blocking(move || {
 // to do some thing block io
  std::fs::read_to_string(path)
});
}

allow replace to Auto deal with

async fn read_to_string(path: impl AsRef<Path>) -> io::Result<String> {
  std::fs::read_to_string(path)
}

Because there are many libraries many IO operations are blocked for historical reasons（Even rust Std libraries） If you use manual differentiation, you'll end up with a huge amount of code。

“async_std” this crate can auto（Inspired by golang）, for example doc. https://async.rs/blog/stop-worrying-about-blocking-the-new-async-std-runtime/

[MikailBag]

async-std's runtime can not detect blocking calls automatically too AFAIK. That pull request from the blog post was closed. UPD: PR itself was https://github.com/async-rs/async-std/pull/631.

[Darksonn]

Hi. You might want to read this quite recent documentation improvement, which should address these questions. The question is also addressed in this blog post, which also explains why async-std's proposed blocking-detection is not comparable to what golang does.

So the answer is: You need to continue using spawn_blocking (or block_in_place) for blocking operations.

I am closing this issue, but feel free to post additional questions here.

[zhuxiujia]

async-std's runtime can not detect blocking calls automatically too AFAIK. That pull request from the blog post was closed. UPD: PR itself was async-rs/async-std#631.

no , do you see https://github.com/async-rs/async-std/pull/733

631 PR is a successor impl in #733 . and it is merged.

This has been merged to master, we will be releasing a 1.6.0-alpha soon

[zhuxiujia]

Hi. You might want to read this quite recent documentation improvement, which should address these questions. The question is also addressed in this blog post, which also explains why async-std's proposed blocking-detection is not comparable to what golang does.

So the answer is: You need to continue using spawn_blocking (or block_in_place) for blocking operations.

I am closing this issue, but feel free to post additional questions here.

Hi, async_std is successful impl this PR. if tokio also can do, it will be cool

[Darksonn]

Tokio does not have any plans to implement such a feature due to its detrimental effects on the tail latencies of the system. The blog post I linked explains why in the “A note on blocking” section.

[hawkw]

async-std's runtime can not detect blocking calls automatically too AFAIK. That pull request from the blog post was closed. UPD: PR itself was async-rs/async-std#631.

no , do you see async-rs/async-std#733

631 PR is a successor impl in #733 . and it is merged.

This has been merged to master, we will be releasing a 1.6.0-alpha soon

My understanding is that the PR you linked (async-rs/async-std#733) does not contain the automatic detection of blocking operations, only internal refactors to the async-std runtime that were factored out from async-rs/async-std#631.

See https://github.com/async-rs/async-std/pull/631#issuecomment-599376318:

One possible way of moving forward could be to keep spawn_blocking(), delete the part that automatically detects blocking tasks, and merge everything else. That would bring us immediate benefits and should be pretty uncontroversial.

And https://github.com/async-rs/async-std/pull/733#issue-391558631::

This PR contains only the following parts:

This PR replaces the current scheduler with a new one. Differences:

    The executor and reactor are more closely coupled. We don't have a networking driver thread anymore. Instead, executor threads poll mio.

What we did in this PR

Removed the mechanism to launch a new thread.
Revived spawn_blocking