3 ms·

So what then is async? If there is no scheduling/preemption in executing an "async" function, it's not really "async", but rather synchronous. Is async just a n

So what then is async? If there is no scheduling/preemption in executing an "async" function, it's not really "async", but rather synchronous. Is async just a new way to say "instruction reordering"? Or is async really just "*defer* until the last possible moment: await"? edit to match yours: not sure what a "green" thread is. In any case, if threads are not an option, an async may always be ignorable, after all, a program may not rely on the order of the execution of its threads/its preemption; that would be a race condition. Textbook definition. As I see it, the fork/join model is very useful for "shingling" code paths that don't have to happen in sequence, but _could_ happen in parallel. Final edit: nothing is otherwise stopping the implementer of async to add a pre-started threadpool to the runtime, with whatever configurable parameters one would want. Post final edit: I think fork/join vs send/sync are just implementation details. But I respect Rust for going with send/sync, just that it doesn't change all that much in terms of the programming interface.

AndrewDucker 5y ago
Async is running many tasks on many less threads, using polling. See https://rust-lang.github.io/async-book/01_getting_started/02_why_async.html https://rust-lang.github.io/async-book/01_getting_started/02...
- steveklabnik 5y ago
  (but note that this doesn't mean busy-loop polling, while that will be used in "my first executor" tutorials, production executors don't call a future until it's ready to have more progress made via an event, often from an epoll/kqueue/iocp or similar mechanism.)
  - bruce343434 5y ago
    this sounds like a lot of overhead, though
    - DenseComet 5y ago
      Rather, Rust just makes this overhead explicit. Go, Node, etc do the same thing, but just hide what actually happens.
    - Groxx 5y ago
      It is, relative to not doing it. But it's quite a lot less overhead than a native thread.
    - chmod775 5y ago
      As opposed to what?
monocasa 5y ago
It's "compile this as a state machine such that when other futures are waited on internally by this function, store stack state in an anonymous struct that implements Future + Poll, and allow repumping when that Poll implemention says it's ready. This allows you to reuse the same stack when this async function is blocked"

AndrewDucker 5y ago

Async is running many tasks on many less threads, using polling. See https://rust-lang.github.io/async-book/01_getting_started/02_why_async.html https://rust-lang.github.io/async-book/01_getting_started/02...

steveklabnik 5y ago
(but note that this doesn't mean busy-loop polling, while that will be used in "my first executor" tutorials, production executors don't call a future until it's ready to have more progress made via an event, often from an epoll/kqueue/iocp or similar mechanism.)
- bruce343434 5y ago
  this sounds like a lot of overhead, though
  - DenseComet 5y ago
    Rather, Rust just makes this overhead explicit. Go, Node, etc do the same thing, but just hide what actually happens.
  - Groxx 5y ago
    It is, relative to not doing it. But it's quite a lot less overhead than a native thread.
  - chmod775 5y ago
    As opposed to what?

monocasa 5y ago

It's "compile this as a state machine such that when other futures are waited on internally by this function, store stack state in an anonymous struct that implements Future + Poll, and allow repumping when that Poll implemention says it's ready. This allows you to reuse the same stack when this async function is blocked"