In our codebase we have both Tokio mutexes and async-lock mutexes, which we must use on wasm32-unknown-unknown due to the Tokio runtime being incompatible with it. We believe it would make sense to create an abstraction over our mutexes that allows us to switch between implementations depending on platform.
At the same time, we have been experiencing deadlocks due to unexpected mutex acquisition and release patterns, which we would like better observability into. Tokio mutexes automatically produce tracing information when using the tracing feature, but async-lock mutexes do not; our wrapper could automatically trace in both cases.
ma2bd
commented
10 months ago
In our codebase we have both Tokio mutexes and
async-lockmutexes, which we must use onwasm32-unknown-unknowndue to the Tokio runtime being incompatible with it. We believe it would make sense to create an abstraction over our mutexes that allows us to switch between implementations depending on platform.At the same time, we have been experiencing deadlocks due to unexpected mutex acquisition and release patterns, which we would like better observability into. Tokio mutexes automatically produce tracing information when using the
tracingfeature, but async-lock mutexes do not; our wrapper could automatically trace in both cases.Issue is from a discussion with @jvff.