_sync vs _async and Drop with HashMap

[mincrmatt12]

The documentation is somewhat vague about the implications of mixing _sync and _async within async blocks, only saying that it could lead to deadlocks (even without holding things across await points) - the underlying saa docs are a bit clearer in outlining how that might happen, but I'm still a bit confused; the usual advice with async is that you can use sync locks so long as you don't hold them across await points.

I have a case where I want to keep an object in a map throughout some scope, using a guard type that removes the item from the map in Drop, but obviously you can't remove_async from within Drop - how bad is it to do remove_sync in the Drop case while still initially insert_async-ing?

Something like (with the scopeguard defer! macro)

if hash_map.insert_async(request_id, ()).await.is_err() { todo!() }
{
  defer! {
    hash_map.remove_sync(request_id);
  }

  // ... long async operations ...
} // exit scope, remove from map.

That case is trivial to rewrite with remove_sync, but you can imagine more involved cases with Try, or the bigger issue of the calling future being cancelled via dropping.

[wvwwvwwv]

the usual advice with async is that you can use sync locks so long as you don't hold them across await points.

That's true for those that only provide synchronous methods, e.g., DashMap or parking_lot. scc is different; its internal locks can be acquired either synchronously or asynchronously. The detailed scenario is described in the saa doc; in short, there is no guarantee that the lock owner task gets scheduled by the asynchronous runtime in case another task is blocking the executor.
-> Calling _sync methods when dropping a Future is still bad; cancelled Futures are dropped within an asynchronous executor.

Therefore, I'd suggest that you make _sync calls in a separate thread or a thread pool outside the asynchronous runtime, or use spawn_blocking or the like.