Re: Delayed vs non-delayed Workqueues usage

Andy Ross

On 11/21/19 8:58 AM, todd_mullanix via Lists.Zephyrproject.Org wrote:
Can you intermix k_work and k_delayed_work structures on the same
Yes, you can. The work queue is the same. The k_delayed_work API is
really just a convenience wrapper for "a work queue item plus a
timeout for when to submit it".

How do you know which structure type to use in the CONTAINER_OF? Do
you have a "type" field before the k_work or k_delayed_work
structure that the handler can query to determine what the real
structure definition is?
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.


Join to automatically receive all group messages.