Re: Delayed vs non-delayed Workqueues usage

Marc Herbert

On 21 Nov 2019, at 09:55, Andy Ross <andrew.j.ross@...> wrote:

It's your (i.e. the code author's) struct. You allocated it, you know
where it lives in its wrapper struct. And that callback is likewise
your function, you registered it at submit time and you know what kind
of work items will be passed as arguments. If you put your struct
k_work inside of a "struct my_doodad", and submit it, then you know
how to get back to the doodad pointer from the work item when the
callback fires.

This nested struct trick is a fairly common pattern in Zephyr, as it
doesn't require a heap or other way to allocate items like struct
k_work in the kernel. The idea is that you (the author) allocate that
k_work (or k_delayed_work) item on the kernel's behalf, and then when
something happens on it (e.g. it's time to run it) you get it as an
argument to the callback you registered.
I think it's the same object-oriented pattern than the Linux one
described in more detail at:

Join to automatically receive all group messages.