Hacker News new | ask | show | jobs
by vbsd 563 days ago
Huh, you're right about this, thanks.

On the other hand, I maintain that this is an incidental rather than essential reason for the program finishing quickly. In that benchmark code, we can replace "sleep" with our custom sleep function which does not record start time before execution:

  async fn wrapped_sleep(d: Duration) {
      sleep(d).await
  }

The following program will still finish in ~10 seconds.

  #[tokio::main]
  async fn main() {
      let num_tasks = 100;
      let mut tasks = Vec::new();
      for _ in 0..num_tasks {
          tasks.push(wrapped_sleep(Duration::from_secs(10)));
      }
      futures::future::join_all(tasks).await;
  }
1 comments

In `wrapped_sleep` function body, where does the `sleep()` come from? It's still tokio::time::sleep, right? If so, the start time is recorded before the first `.await`.

Regardless, the program you provided _does_ actually run the futures concurrently, because of the `join_all()`. My point above was that in the original blog post, the appendix has a version without `join_all()`, which has no concurrency.

Ah, I missed that you were talking about the code in the appendix, not the top examples. Yeah, you’re right on every count then, aplologies.