Unexpected productivity boost of Rust

How do you encode the locking issue in the type system, it seems magical? Can you just never hold any locks when calling await, is it smart enough to know that this scheduler might move work between threads?

Presumably the author is using tokio which requires the future constructed (e.g the async function) to be Send (either because of the rules of Rust or annotated as Send) since tokio is a work-stealing runtime and any thread might end up executing a given future (or even start executing and then during a pause move it for completion on another thread). std::sync::MutexGuard intentionally isn't annotated with Send because there are platforms that require the acquiring thread be the one to unlock the mutex.

One caveat though - using a normal std Mutex within an async environment is an antipattern and should not be done - you can cause all sorts of issues & I believe even deadlock your entire code. You should be using tokio sync primitives (e.g. tokio Mutex) which can yield to the reactor when it needs to block. Otherwise the thread that's running the future blocks forever waiting for that mutex and that reactor never does anything else which isn't how tokio is designed).

So the compiler is warning about 1 problem, but you also have to know to be careful to know not to call blocking functions in an async function.

Using a Tokio mutex is even more of an antipattern :) come to my RustConf talk about async cancellation next week to find out why!

Most people on this forum are not attending RustConf. It might be helpful to post at least the abstract of your idea.

The big thing is that futures are passive, so any future can be cancelled at any await point by dropping it or not polling it any more. So if you have a situation like this, which in my experience is a very common way to use mutexes:

  let guard = mutex.lock().await;
  // guard.data is Option<T>, Some to begin with
  let data = guard.data.take(); // guard.data is now None

  let new_data = process_data(data).await;
  guard.data = Some(new_data); // guard.data is Some again

Then you could cancel the future at the await point in between while the lock is held, and as a result guard.data will not be restored to Some.

I'm not sure this introduces any new failure though:

    let data = mutex.lock().take();
    let new_data = process_data(data).await;
    *mutex.lock() = Some(new_data);

Here you are using a traditional lock and a cancellation at process_data results in the lock with the undesired state you're worried about. It's a general footgun of cancellation and asynchronous tasks that at every await boundary your data has to be in some kind of valid internally consistent state because the await may never return. To fix this more robustly you'd need the async drop language feature.

True! This is the case with std mutexes as well. But holding a std MutexGuard across an await point makes the future not Send, and therefore not typically spawnable on a Tokio runtime [1]. This isn't really an intended design decision, though, as far as I can tell -- just one that worked out to avoid this footgun.

Tokio MutexGuards are Send, unfortunately, so they are really prone to cancellation bugs.

(There's a related discussion about panic-based cancellations and mutex poisoning, which std's mutex has but Tokio's doesn't either.)

[1] spawn_local does exist, though I guess most people don't use it.

You argument then is that the requirement to acquire the lock multiple times makes it more likely you'll think about cancellation & keeping it in a valid interim state? Otherwise I'm not sure how MutexGuards being send really makes it any more or less prone to cancellation bugs.