Re: [PATCH v1 1/2] rust: Add support for calling a function exactly once

Andreas Hindborg
2025-11-11T09:12:47Z

Boqun Feng <boqun.feng@gmail.com> writes:

> On Tue, Nov 11, 2025 at 12:09:49PM +0900, FUJITA Tomonori wrote:
>> On Mon, 10 Nov 2025 08:14:56 -0800
>> Boqun Feng <boqun.feng@gmail.com> wrote:

<cut>

>> Anyway, I tried and got a following compile error:
>>
>> error[E0277]: `core::cell::UnsafeCell<core::mem::MaybeUninit<()>>` cannot be shared between threads safely
>> --> /home/fujita/git/linux-rust/samples/rust/rust_configfs.rs:109:9
>> |
>> 109 | kernel::pr_info_once!("print once\n");
>> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `core::cell::UnsafeCell<core::mem::MaybeUninit<()>>` cannot be shared between threads safely
>>
>>
>> We need Sync for SetOnce? I haven't been following the SetOnce
>
> Yes, I think `SetOnce<T>` should be `Sync` if T is `Sync`. So good
> finding!

@Tomonori you can include a patch to add the impl, if you end up using
`SetOnce`.

> I would say it's actually the effort of trying to reuse the
> existing solution makes that we find places that needs to be improved.
>
> @Andreas, thoughts?

Sorry, I did not follow this branch of the thread yet. Please see my
comment on the other branch of the thread tree.

TLDR, I agree we should reuse if we could, but I am unsure if external reset
would violate some rules. I think we should modify `SetOnce` to support
this use case if we can.

>
>> discussion, but I wonder if there are use cases that require Sync. If
>> all access goes through its methods, it seems safe to add Sync.
>>
>>
>> I personally prefer the OnceLite implementation of not using SetOnce,
>> however since it's not directly used by users and can be easily
>> changed later, so I'm fine with any implementation as long as we can
>> reach an agreement soon.
>>
>
> We should always try to find a unified solution, if there is not much
> trouble. Otherwise, we will end up having MyOnce, YourOnce, HisOnce,
> HerOnce, TheirOnce etc in our code base.

I agree.

Best regards,
Andreas Hindborg