3 ms·

> You'd essentially be creating a very ergonomical shortcut to fork-join multithreading which is infinitely more powerful and expressive than whatever this "asy

> You'd essentially be creating a very ergonomical shortcut to fork-join multithreading which is infinitely more powerful and expressive than whatever this "async function" stuff is. But that would require starting other threads, which requires everything to be `Send + Sync`, has the overhead of multithreading, and can't be managed with any sort of scheduler (without platform-specific hacks). Unless you use green threads, and that's discussed in the article.

bruce343434 5y ago
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"

bruce343434 5y ago

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"