Re: [PATCH v2 02/14] rust: hrtimer: introduce hrtimer support
From: Benno Lossin
Date: Mon Sep 23 2024 - 13:00:08 EST
On 23.09.24 18:35, Andreas Hindborg wrote:
> "Benno Lossin" <benno.lossin@xxxxxxxxx> writes:
>> On 19.09.24 07:43, Andreas Hindborg wrote:
>>>>> + /// until the timer is unarmed and the callback has completed.
>>>>> + ///
>>>>> + /// Note: It must be safe to leak the handle.
>>>>> + type TimerHandle: TimerHandle;
>>>>
>>>> Why does this need to be an associated type? Couldn't we have a
>>>> `TimerHandle<T>` struct? The schedule function below could then return
>>>> `TimerHandle<Self>`.
>>>
>>> At one point, I had some cycles in trait resolution. Moving generics to
>>> associated types solved that issue. Maybe this can be changed to a
>>> generic. But are generics preferred over associated types for some
>>> reason?
>>
>> The associated type is more complicated IMO, because then every
>> implementer of the trait needs to create one. If we can avoid that, I
>> would prefer a generic type.
>
> When you say create, you mean specify?
Yes.
> Users would not invent their own type to put here, they would use the
> types defined by the `hrtimer` module in later patches.
I mean the implementers of this trait, not the users of the trait. You
define an `ArcTimerHandle`, `PinTimerHandle` and a `PinMutTimerHandle`
in this series. I think we can avoid that using a single generic struct.
---
Cheers,
Benno