Messages in this thread | | | Date | Wed, 31 May 2023 09:07:58 +0000 | Subject | Re: [PATCH v1 6/7] rust: workqueue: add safe API to workqueue | From | Alice Ryhl <> |
| |
Benno Lossin <benno.lossin@proton.me> writes: > On Wednesday, May 17th, 2023 at 22:31, Alice Ryhl <aliceryhl@google.com> wrote: >> +macro_rules! define_work_adapter_newtype { >> + ( >> + $(#[$outer:meta])* >> + $pub:vis struct $name:ident( >> + $(#[$innermeta:meta])* >> + $fpub:vis Arc<$inner:ty> $(,)? >> + ); >> + $($rest:tt)* >> + ) => { >> + $(#[$outer])* >> + $pub struct $name($(#[$innermeta])* $fpub $crate::sync::Arc<$inner>); > > I am a bit confused as to why these types *contain* a pointer. Shouldn't > these be exactly the same `Work<$inner>`, except they allow multiple `run` > functions? So IMO they should embed a `Work<$inner>` and the > manually defined `run` function would take a `$inner`.
No, that's not how this particular patch was designed. With the design I used, the way you tell `enqueue` which `work_struct` field you want to use is by using a different pointer type for each `work_struct` field. This macro defines those pointer types.
So, for example, if you have only one `work_struct` field, then you just use `Arc<MyStruct>` as your pointer type, and the field has type `Work<Arc<MyStruct>>`.
On the other hand, if you have two `work_struct` fields, then you instead use the macro to define `MyPointerType1` and `MyPoinerType2` that both wrap an `Arc<MyStruct>`, and the fields then have types `Work<MyPointerType1>` and `Work<MyPointerType2>`.
Alice
| |