Re: [PATCH v2 2/2] rust: sync: Introduce LazyInit

[Alice Ryhl <aliceryhl@google.com>]

On Fri, May 29, 2026 at 01:30:42PM -0400, Lyude Paul wrote:
> SetOnce is nice, but it does have one problem - you can't use it with
> fallible initializers. While we will be adding support for doing that with
> SetOnce, this leads into another problem: There's no way for racing callers
> to actually block on the initialization of SetOnce, which makes it a
> difficult type to use safely for situations where we want to initialize
> data fallibly once, and then provide access to it to multiple users at once
> until drop.
> 
> So to solve this, introduce a new type: LazyInit. LazyInit is like SetOnce
> with a couple of important differences:
> 
> * It can't be used in const context
> * It can handle in-place fallible initializers.
> * It uses a Mutex for synchronization instead of an atomic, allowing
>   callers to block on initialization.
> * It requires its contents already be Send + Sync, since the Mutex protects
>   initializing data and not the data itself.
> 
> Signed-off-by: Lyude Paul <lyude@redhat.com>

> +    /// Retrieve the contents of `inner.data` and extend their lifetime.
> +    ///
> +    /// # Safety
> +    ///
> +    /// The caller guarantees that `self.inner.data` has been previously initialized.
> +    #[inline(always)]
> +    unsafe fn data<'a>(&'a self, inner: &MutexGuard<'_, Inner<T>>) -> &'a T {
> +        // SAFETY:
> +        // - Our safety contract guarantees `inner.data` is initialized.
> +        // - `T` is `Send` + `Sync`, and thus does not need the `Mutex` for synchronization, making
> +        //   it safe to hold onto outside of the lock.
> +        // - We're guaranteed via `Inner`'s type invariants that so long as immutable references to
> +        //   self exist, `data` cannot be uninitialized - ensuring it lives throughout the lifetime
> +        //   of A.
> +        // - We're guaranteed the container of `T` will not be written to via `Inner`s type
> +        //   invariants until `Drop`, ensuring it remains populated for the lifetime of 'a.
> +        unsafe { mem::transmute::<&_, &'a _>(inner.data.assume_init_ref()) }

I'm not a big fan of using these kinds of tricks to access the contents
of a mutex after unlocking it. Could we instead use a struct like this:

struct LazyInit<T> {
    data: UnsafeCell<MaybeUninit<T>>,
    set: AtomicBool,
    lock: Mutex<()>,
}

or even:

struct LazyInit<T> {
    data: SetOnce<T>,
    lock: Mutex<()>,
}

I think this logic will be simpler for everyone.

By the way, another option is to use a similar strategy to
https://lore.kernel.org/rust-for-linux/20260523-upgrade-poll-v4-2-f5b4c747eac2@google.com/
where you just use SetOnce and protect calls to `populate` by another
mutex in the structure. Then you don't need a separate LazyInit.

Alice