Lines Matching refs:handler

66 A work item is assigned a **handler function**, which is the function
72 item's handler function and marks it as not pending.
78 item from the queue and invoke the work item's handler function. Depending on
101 A handler function can use any kernel API available to threads. However,
104 its queue until the handler function finishes executing.
106 The single argument that is passed to a handler function can be ignored if it
107 is not required. If the handler function requires additional information about
109 structure. The handler function can then use the argument value to compute the
119 A handler function is permitted to re-submit its work item argument
121 This allows the handler to execute work in stages, without unduly delaying
128     handler function needs to perform its work must not be altered until
129     the handler function has finished executing.
151 Note that work handler used for delayable still receives a pointer to the
313     /* install my_isr() as interrupt handler for the device (not shown) */
372 :c:struct:`k_work` that is passed to a work handler function.
416 filled by an ISR or thread and read by the work handler.
451 Note that submitting from the work handler can fail if the work item had been
453 once the handler finishes.  If it is not, the code above must take other steps
461 delayable work item is being rescheduled in its handler due to inability to
476   animated by work handler activity to become non-responsive.
479   being run by a handler.  Proceeding to manipulate state shared with the work
480   handler will result in data races that can cause failures.
493    /* If this fails, the work handler will check pub->active and
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:
522 are submitted, you may be able to have everything done in the work handler