Every language pitches async/await as synchronous-looking code, and the same two keywords appear everywhere. But behind the shared syntax hide nine independent design decisions, and no two of seven modern runtimes agree on what even the simplest async programs should do! In this paper we map the design space of async/await so you can find out where your language stands.
  • Alavi@programming.dev
    2·
    18 days ago

    This is so awesome and so far beyond my current knowledge!

    I’m trying to learn and wrap my head around concurrency in Clojure recently. I only know asynchronous programming in Javascript. The mental model in JS for async itself, isn’t very complex. Because it’s a single thread. But in Clojure, you also have multiple threads so you can have multi threading and async at the same time.

    From what I understand, Clojure has made it super simple, but I still haven’t understood it.

  • TehPers@beehaw.orgEnglish
    2·
    17 days ago

    From the paper:

    The most straightforward approach is unaware cancellation, where a task has no opportunity to react to being cancelled. This approach is taken by Rust in both Tokio and Smol. In Rust, cancellation essentially means never executing a coroutine again after it has yielded. With a direct handle on the coroutine, this simply means not polling the coroutine, or explicitly dropping it.

    Maybe I’m misunderstanding this, but at least with Tokio, aborting a task causes it to be stopped and dropped at the next await point. Also, in Rust, the conventional way to cancel a future is to drop it.

    By dropping the future, you are signaling to it that it has been canceled. A future can respond to this by implementing Drop, which gives it an opportunity to do whatever it wants (usually some kind of cleanup but it can go as far as making blocking database calls if it wants to).

    Sure, some other languages work by throwing some kind of exception that bubbles up, or you can check a cancellation token or abort signal or whatever to see if the task is canceled. Using Drop is just another way to accomplish the same thing.

    • lad@programming.devEnglish
      1·
      17 days ago

      I’m guessing, they mean the user of a future that already exists as it is, what you mean is you can implement a future that would provide a way for the code inside to know of being cancelled. But most of the time you don’t do that, and a function that was polled once and then dropped will never know about that

  • aev_software@programming.dev
    33·
    19 days ago

    Personally, I hate awaiting async actions and prefer callbacks. Just execute when done, thanks. I don’t care in which order.