Lines Matching refs:can
16 Any number of workqueues can be defined (limited only by available RAM). Each
31 A workqueue must be initialized before it can be used. This sets its queue to
63 Any number of **work items** can be defined. Each work item is referenced
71 A work item must be initialized before it can be used. This records the work
90 A work item can be in multiple states; for example it can be:
101 A handler function can use any kernel API available to threads. However,
106 The single argument that is passed to a handler function can be ignored if it
108 the work it is to perform, the work item can be embedded in a larger data
109 structure. The handler function can then use the argument value to compute the
137 only after a specified period of time, rather than immediately. This can be
212 incurs a significant cost in memory footprint. A new workqueue can be
250 rescheduling can be controlled by the optional final parameter; see
253 The following API can be used to interact with a workqueue:
255 * :c:func:`k_work_queue_drain()` can be used to block the caller until the
258 thread or ISR are rejected. The restriction on submitting more work can be
275 An initialized work item can be submitted to the system workqueue by
279 The following code demonstrates how an ISR can offload the printing
317 The following API can be used to check the status of or synchronize with the
334 can be used after :c:func:`k_work_cancel()` is invoked (from an ISR)` to
370 The helper function :c:func:`k_work_delayable_from_work()` can be used to get
374 The following additional API can be used to check the status of or synchronize
390 While the state of both regular and delayable work items can be determined
395 can be invoked from thread context to wait until the requested state has been
422 If the selected lock mechanism can :ref:`api_term_sleep` then allowing the
451 Note that submitting from the work handler can fail if the work item had been
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
480 handler will result in data races that can cause failures.
513 indication can be obsolete by the time the test is returned, and a "not-busy"
514 indication can also be wrong if work is submitted from multiple contexts, or
519 that can be checked by the handler to confirm whether there is work to be
520 done. This way you can use the work handler as the standard cleanup path: