new | ask | show | jobs
cogman10 3 days ago  [ - ]

Wait, how does this work in practice?

Let's say my code looks like this

    async fn a() {
      b().await
    }

    async fn b() {
      c().await
      d().await
    }

    async fn c() {
    }

    async fn d() {
    }
Where does an issue occur which causes `d` to not to be called? Is it some sort of cancellation in c? Or some upstream action in a?
cogman10 3 days ago  [ - ]

Ah, I see it now in the article. I just missed it.

`d` not being called would happen because of actions in `a`.

If `a` were rewritten as

    async fn a() {
      try_join!(b(), c(), d())
    }
Then if `c` ends up failing in the try_join then process on `b` will be halted and thus the `d` in `b` won't be executed.
alfiedotwtf 2 days ago  [ - ]

Maybe I’m thick, but I’m not seeing what is the problem in your first codeblock?

cogman10 2 days ago  [ - ]

There's nothing wrong in my first comment, it's the second that clarifies adding a `try_join` at the top of the stack can break things below (which is what I was trying to figure out in my initial comment).

Because rust is ultimately constructing a state machine which is ran by the caller, the execution of that state machine can be interrupted or partially executed at any of the `await` points. Or more accurately the caller can simply not advance the state machine.

So, the `try_join` macro can start work on the various functions and if any of them fail, the others are ultimately cancelled. Which can happen before those functions finish fully executing.

This is particularly bad if there's a partial state change.

I'm not entirely sure what that means for memory allocation.