Re: [PATCH v2 02/14] rust: hrtimer: introduce hrtimer support

[Andreas Hindborg]

Benno Lossin <benno.lossin@xxxxxxxxx> writes:

> 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.

It is not immediately clear for me how to do this. For `Box` we have:

pub struct BoxTimerHandle<U>
where
    U: HasTimer<U>,
{
    pub(crate) inner: *mut U,
}

but for `Pin<&U>` we have

pub struct PinTimerHandle<'a, U>
where
    U: HasTimer<U>,
{
    pub(crate) inner: Pin<&'a U>,
}

How can these be combined to a single generic struct?


Best regards,
Andreas