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

One should always keep in mind that await is always a potential return point. So, using await between two actions which always should be performed together should be avoided.

Spivak 3 days ago  [ - ]

That… seems bad? Like I guess it is what it is and you just have to deal with it but what if your "critical section" has two await calls? The code can be paused between them but it's such that it must eventually resume. Say making a change in the database and emitting an audit edit for that change. Is your only option to either not do that or put a big do not cancel sign on the function docs?

setr 3 days ago  [ - ]

Even if you guaranteed the calling code would always logically continue running the function till completion, you wouldn’t have the guarantee the code would actually resume — eg the program crashes between the two calls, network dies, etc.

If you want to tie multiple actions together as an atomic unit, you need the other side to have some concept of transactions; — and you need to utilize it.

diarrhea 3 days ago  [ - ]

A DB action and audit emission have to run transactionally anyway.

So on cancellation, the transaction times out and nothing is written. Bad but safe.

The problem is the same on other platforms. For example, what if writing to the DB throws an exception if you’re on Python? Your app just dies, the transaction times out. Unfortunate but safe.

If it does not run transactionally you have a problem in any execution scenario.

sunshowers 3 days ago  [ - ]

So, regarding transactions, absolutely you can throw them away on cancellation. But there's an interesting wrinkle here: if you use a connection pool like most users, and you were going to do the ROLLBACK at the end of your future on error, then that ROLLBACK wouldn't run it the future is cancelled! Then future operations reusing the same connection would be stuck in transaction la-la land.

(This is related to the fact that Rust doesn't have async drop — you can't run async code on drop, other than spawning a new task to do the cleanup.)

This is prong 3 of my cancel correctness framework (that the cancellation violates a system property, in this case a cleanup property.) The solution here is to ensure the connection is in a pristine state before handing it out the next time it's used.

sunshowers 3 days ago  [ - ]

In general I think people end up gravitating towards using message passing or the actor model for this.

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.