Lines Matching full:item
11 work items in a first in, first out manner. Each work item is processed by
12 calling the function specified by the work item. A workqueue is typically
28 between each submitted work item, to prevent a cooperative workqueue from
40 caller need not be concerned that an item may be processing when the
46 * The ability to wait until a work item has completed or a queue has been
48 * Finer control of behavior when scheduling a delayable work item,
50 item is scheduled again.
51 * Safe handling of work item resubmission when the item is being processed
60 Work Item Lifecycle
63 Any number of **work items** can be defined. Each work item is referenced
66 A work item is assigned a **handler function**, which is the function
67 executed by the workqueue's thread when the work item is processed. This
68 function accepts a single argument, which is the address of the work item
69 itself. The work item also maintains information about its status.
71 A work item must be initialized before it can be used. This records the work
72 item's handler function and marks it as not pending.
74 A work item may be **queued** (:c:enumerator:`K_WORK_QUEUED`) by submitting it to a
75 workqueue by an ISR or a thread. Submitting a work item appends the work item
78 item from the queue and invoke the work item's handler function. Depending on
80 other items in the queue, a queued work item may be processed quickly or it
83 A delayable work item may be **scheduled** (:c:enumerator:`K_WORK_DELAYED`) to a
86 A work item will be **running** (:c:enumerator:`K_WORK_RUNNING`) when it is running
90 A work item can be in multiple states; for example it can be:
94 wait until the work item completed);
98 *all simultaneously*. A work item that is in any of these states is **pending**
108 the work it is to perform, the work item can be embedded in a larger data
113 A work item is typically initialized once and then submitted to a specific
115 to submit a work item that is already queued the work item is not affected;
116 the work item remains in its current place in the workqueue's queue, and
119 A handler function is permitted to re-submit its work item argument
120 to the workqueue, since the work item is no longer queued at that time.
125 A pending work item *must not* be altered until the item has been processed
126 by the workqueue thread. This means a work item must not be re-initialized
127 while it is busy. Furthermore, any additional information the work item's
136 An ISR or a thread may need to schedule a work item that is to be processed
138 done by **scheduling** a **delayable work item** to be submitted to a
141 A delayable work item contains a standard work item but adds fields that
142 record when and where the item should be submitted.
144 A delayable work item is initialized and scheduled to a workqueue in a similar
145 manner to a standard work item, although different kernel APIs are used. When
148 kernel submits the work item to the specified workqueue, where it remains
170 item in response to a **poll event** (see :ref:`polling_v2`), that will
176 A triggered work item is a standard work item that has the following
179 * A pointer to an array of poll events that will trigger work item
184 A triggered work item is initialized and submitted to a workqueue in a similar
185 manner to a standard work item, although dedicated kernel APIs are used.
188 object's changes state, the work item is submitted to the specified workqueue,
192 The triggered work item as well as the referenced array of poll events
194 item lifecycle, from submission to work item execution or cancellation.
196 An ISR or a thread may **cancel** a triggered work item it has submitted
263 item will silently fail to be submitted.
267 Submitting a Work Item
270 A work item is defined using a variable of type :c:struct:`k_work`. It must
275 An initialized work item can be submitted to the system workqueue by
281 to resubmit the work item while it is still queued, the work item is left
300 void print_error(struct k_work *item)
303 CONTAINER_OF(item, struct device_info, work);
310 /* initialize work item for printing device's error messages */
318 work item:
320 * :c:func:`k_work_busy_get()` returns a snapshot of flags indicating work item
327 item has completed. It returns immediately if the work is not pending.
328 * :c:func:`k_work_cancel()` attempts to prevent the work item from being
337 Scheduling a Delayable Work Item
340 A delayable work item is defined using a variable of type
351 attempts to schedule the same item with this API before the delay completes
352 will not change the time at which the item will be submitted to its queue.
361 If the work item is not scheduled both APIs behave the same. If
362 :c:macro:`K_NO_WAIT` is specified as the delay the behavior is as if the item
375 with the work item:
410 Sometimes the data a work item must process is naturally thread-safe, for
435 /* NB: Submit will fail if the work item is being cancelled. */
448 delayable work item is preferred, and the work should be (re-)scheduled with a
451 Note that submitting from the work handler can fail if the work item had been
459 resubmit as long as you're sure that eventually the item will take its lock
461 delayable work item is being rescheduled in its handler due to inability to
464 the cancellation and avoid the cancelled work item being submitted again after
473 * Submitting a work item (:c:func:`k_work_submit_to_queue`) can fail if the
478 :c:func:`k_work_cancel_delayable`) can complete while the work item is still
505 and interrupts. Attempts to externally inspect a work item's state and make
509 checking whether the work item is already submitted by inspecting snapshot