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 async-rs/async-std#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 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

[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 async-rs/async-std#631 (comment):

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 async-rs/async-std#733 (comment)::

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