Re: [PATCH v12 4/6] rust: ww_mutex: add Mutex, AcquireCtx and MutexGuard

[Gary Guo]

On Thu Oct 15, 2026 at 1:13 PM BST, Onur Özkan wrote:
>> > +
>> > +    /// Similar to [`Self::lock`], but can be interrupted by signals.
>> > +    ///
>> > +    /// # Safety
>> > +    ///
>> > +    /// The same requirements as [`Self::lock`] apply.
>> > +    pub unsafe fn lock_interruptible<'a, T>(
>> > +        &'a self,
>> > +        mutex: &'a Mutex<'a, T>,
>> > +    ) -> Result<MutexGuard<'a, T>> {
>> > +        lock_common(mutex, Some(self), LockKind::Interruptible)
>> > +    }
>> > +
>> > +    /// Tries to lock the [`Mutex`] on this [`AcquireCtx`] without blocking.
>> > +    ///
>> > +    /// Unlike [`Self::lock`], no deadlock handling is performed.
>> > +    ///
>> > +    /// # Safety
>> > +    ///
>> > +    /// The same requirements as [`Self::lock`] apply.
>> > +    pub unsafe fn try_lock<'a, T>(&'a self, mutex: &'a Mutex<'a, T>) -> Result<MutexGuard<'a, T>> {
>> > +        lock_common(mutex, Some(self), LockKind::Try)
>> > +    }
>> > +}
>> > +
>> > +#[pinned_drop]
>> > +impl PinnedDrop for AcquireCtx<'_> {
>> > +    fn drop(self: Pin<&mut Self>) {
>> 
>> I wonder if we can just do
>> 
>>     let acquired = unsafe { (*self.inner.get()).acquired };
>>     assert!(!acquired);
>> 
>> to get rid of the `unsafe`. Somewhat similar to what we do with srcu. Of course,
>> ultimately we want to use `!Leak` for this and can remove the check.
>
> I didn't understand this. You also wrote an unsafe code?

Sorry, I meant to get rid of "unsafe" for `lock`/`try_lock` APIs, because by
adding the assertion we don't have to worry about leaked guards.

Best,
Gary