undefined | Better HN

0 pointssunshowers7mo ago0 comments

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.

0 comments

vlovich1237mo ago

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.

sunshowersOP7mo ago

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.

vlovich1237mo ago

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.

2 more replies

neandrake7mo ago

Same would be true for any resource that needs cleaned up, right? Referring to stop-polling-future as canceling is probably not good nomenclature. Typically canceling some work requires cleanup, if only to be graceful let alone properly releasing resources.

sunshowersOP7mo ago

Yes, this is true of any resource. But Tokio mutexes, being shared mutable state, are inherently likely to run into bugs in production.

In the Rust community, cancellation is pretty well-established nomenclature for this.

Hopefully the video of my talk will be up soon after RustConf, and I'll make a text version of it as well for people that prefer reading to watching.

neandrake7mo ago

Thank you, I look forward to watching your presentation.

j / k navigate · click thread line to collapse

0 pointssunshowers7mo ago0 comments

  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.

0 comments

vlovich1237mo ago

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);

sunshowersOP7mo ago

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.

vlovich1237mo ago

2 more replies

neandrake7mo ago

sunshowersOP7mo ago

Yes, this is true of any resource. But Tokio mutexes, being shared mutable state, are inherently likely to run into bugs in production.

In the Rust community, cancellation is pretty well-established nomenclature for this.

Hopefully the video of my talk will be up soon after RustConf, and I'll make a text version of it as well for people that prefer reading to watching.

neandrake7mo ago

Thank you, I look forward to watching your presentation.

j / k navigate · click thread line to collapse