Support generic tasks or improve documentation on why it's not possible (and perhaps suggest workarounds)

[runfalk]

I was looking at #1837 which didn't really have a resolution, in my mind. So this feature request comes from a bit of ignorance as I don't know why this wouldn't be possible. The best work around for now seems to be to generate tasks using a macro.

What I basically want is the ability to hand a task any device like Spi, Pwm Uart, etc. It seems to me like the proc macro is making the function generic (on nightly) behind the scenes using RPIT, so some level of genericness seems possible at least? Based on the mentioned issue it seems like it was possible to bypass the macro check using TAIT in arguments to make it compile as well.

If there is a fundamental blocker I think it would be very helpful to have some documentation on how this can be worked around.

On a separate note, I've been trying out Embassy for a small project at work and it has been a breath of fresh air for embedded development. 👍

[chrisprice]

I'm new to this project as well but I recently had the same thought (and would like to double check my reasoning!) so thought I'd share my understanding.

An async executor needs to be able to know about the tasks that it is responsible for polling. Additionally those tasks need somewhere to store their in-progress state. In embassy (on stable) the latter is achieved as follows -

1. An async function undergoes compiler magic to transform it into an unnamed type we'll call F, which implements Future. This type encompasses the in-progress state of the function and so its size depends directly on the types used by the function.
2. To use an async function with embassy, a task is created using the embassy_executor::task annotation macro. It's implementation wraps the annotated function in a new function (accepting the same arguments).
3. The wrapper function additionally declares a local static variable which is a reference TaskPoolRef to the TaskPool<F> for the original function.
4. When invoked the wrapper uses this reference to create a task by adding a closure, capturing the wrapped function and the invocation arguments, to the pool and returning a reference TaskRef (SpawnToken is a newtype wrapping a TaskRef for a few reasons inconsequential to this explanation).

The crux of the generics issue is that (source) -

A static item defined in a generic scope (for example in a blanket or default implementation) will result in exactly one static item being defined, as if the static definition was pulled out of the current scope into the module. There will not be one item per monomorphization.

The problematic code is happening across steps 3 & 4 above. Breaking it down -

1. The generically typed TaskPool<F> is lazily allocated on first access by TaskPoolRef using an Arena.
2. The allocation size if based on the inferred (i.e. _) type of F for this first (monomorhpized) instance.
3. Subsequent access to the TaskPool<F> is via TaskPoolRef which unsafely casts to the inferred type of F for this (monomorhpized) instance.

This works fine assuming there is only one F - the first (monomorhpized) instance is thereby guaranteed to be the only (monomorhpized) instance. Embassy enforces this invariant by preventing generic types (along with other checks e.g. no variadics).

If this invariant wasn't there, these different (monomorhpized) instances could potentially require different amounts of memory to store and/or be storing different types and/or in a different order. Thereby resulting in undefined behaviour after the unsafe cast.

On nightly, TAIT allows F to be named as Fut and used in a static type, thereby delegating responsibility for upholding the invariant to the compiler. This also eliminates the need for TaskPoolRef because TaskPool<F> can be statically defined as TaskPool<Fut>.

TLDR; with or without TAIT you somehow need to ensure there is a static TaskPool<F> for each F, meaning you need to define a task per F.

Here's an example of how this invariant could be lifted in a std context. However, applying that here would require some form of runtime allocation with the typical problems that would involve.

An outstanding question I had was - does nightly's use of TAIT allow the explicit generic check to be removed? Quickly butchering the macro code and hacking the tests suggests it should work although the error is obtuse so I can see the benefit of leaving it in place -

    #[task]
    async fn task1<T>(trace: T) where T: Tracer + 'static {
        trace.push("poll task1")
    }

error: type parameter `T` is part of concrete type but not used in parameter list for the `impl Trait` type alias
  --> tests/test.rs:65:5
   |
65 |     #[task]
   |     ^^^^^^^
   |
   = note: this error originates in the attribute macro `task` (in Nightly builds, run with -Z macro-backtrace for more info)

[pawel00100]

I'm new to the Rust, and stumbled at similar problem. I found out that passing impl with 'static often works.
Example GPIO task (with Flex that supports both reads and writes

#[embassy_executor::task]
async fn touch_task(
    mut flex:  Flex<'static, impl Pin + 'static>,
    ...
)

and PWM

#[embassy_executor::task]
async fn pwm_task(
    mut pwm: Pwm<'static, impl embassy_rp::pwm::Channel>,
    ...
) {
   ...
}

[chrisprice]

Interesting, I hadn't tried that. I think it's an embassy bug though.

Based on my reasoning above, I would expect that the block on generics is meant to extend to impl T. No matter whether it's qualified with 'static (I understand this to just disallow implementations that are or contain non-static references), nor its nested depth in the argument type (e.g. impl T, T<impl U>, etc.). However, I can't see any checks for it.

I think it's just happening to work in this case because the types implementing the Pin/Channel trait happen to have a compatible memory layout (read as - undefined behaviour). Or possibly you're only using a single implementation in your binary? Not sure...

[Dirbaio]

oh yes this is definitely a bug!

[yanshay]

I stumbled on this error which brought me here.
I have a task with this signature that I managed to get to compile:

#[embassy_executor::task]
pub async fn some_task (some_struct: SomeStruct<'static, &'static mut TcpSocket<'static>, 4096, 4096>)

Does this limitation mean that I need to duplicate myself the entire function's code for every TcpBuffer with different buffers sizes?

Is there any way to workaround that?

[CBJamo]

I use a non-task async function and wrap that in a tiny task, like this:

#[embassy_executor::task]
pub async fn some_task_0 (some_struct: SomeStruct<'static, &'static mut TcpSocket<'static>, 1024, 1024>) {
    some_task_inner(some_struct).await
}

#[embassy_executor::task]
pub async fn some_task_1 (some_struct: SomeStruct<'static, &'static mut TcpSocket<'static>, 4096, 4096>) {
    some_task_inner(some_struct).await
}

async fn some_task_inner<const A: usize, const B: usize> (some_struct: SomeStruct<'static, &'static mut TcpSocket<'static>, A, B>)

Edited to actually .await the inner task in case someone copy-pastes.

[yanshay]

Thanks, that's simple.

Need to await the inner task inside the calling async fn, right?

[CBJamo]

Ah, you sure do, that's what I get for writing code in the github comment box.

[yanshay]

I got stuck with this limitation again.

I want to write a library that includes and runs an embassy task.
That embassy task is dependent on structs defined by the application using that library.
Given that the task itself has to be in the library and not in the application code, I can't use the workaround above of wrapping the generic async fn with an embassy task because that embasy task needs to be in the library.

Any way to workaround that?

[Dirbaio]

The recommendation for libs is to return a "Runner" object and tell the user to spawn themselves a task that calls runner.run().await. See crates embassy-net, embassy-usb, cyw43, etc for examples of this pattern.

This way the user can use concrete types for their application in the task, not needing generics. As a bonus it makes your lib compatible with executors other than embassy-executor.