Lines Matching full:task

13 thread context, where the output can be consumed, and the task told to continue,
29 of a task and that of the wsi are not necessarily linked.
31 You may start a long task, eg, that runs atomically in its thread for 30s, and
34 There are arrangements that a task can "check in" periodically with lws to see
35 if it has been asked to stop, allowing the task lifetime to be related to the
38 For that reason, at wsi close an ongoing task can detach from the wsi and
40 that work, the task is created with a `cleanup` callback that performs any
41 freeing independent of still having a wsi around to do it... the task takes over
42 responsibility to free the user pointer on destruction when the task is created.
48 Once created, although tasks may run asynchronously, the task itself does not
50 service thread context queries the task state with `lws_threadpool_task_status()`
51 may the task be reaped and memory freed.
55 If a task became detached from its wsi, then joining the done queue is enough
56 to get the task reaped, since there's nobody left any more to synchronize the
79 #### Task creation / destruction
86 wsi|The wsi the task is initially associated with
88 task|A pointer to the function that will run in the pool thread
92 to simplify naming the task with string elements related to who started it
95 #### The task function itself
97 The task function receives the task user pointer and the task state.  The
98 possible task states are
102 LWS_TP_STATUS_QUEUED|Task is still waiting for a pool thread
103 LWS_TP_STATUS_RUNNING|Task is supposed to do its work
104 LWS_TP_STATUS_SYNCING|Task is blocked waiting for sync from lws service thread
105 LWS_TP_STATUS_STOPPING|Task has been asked to stop but didn't stop yet
106 LWS_TP_STATUS_FINISHED|Task has reported it has completed
107 LWS_TP_STATUS_STOPPED|Task has aborted
109 The task function will only be told `LWS_TP_STATUS_RUNNING` or
111 user task and STOPPING means clean up and return `LWS_TP_RETURN_STOPPED`.
113 If possible every 100ms or so the task should return `LWS_TP_RETURN_CHECKING_IN`
117 until the running task finishes, and since the wsi may have gone, the work
120 The task function may return one of
125 LWS_TP_RETURN_SYNC|Task wants to trigger a WRITABLE callback and block until lws service thread res…
126 LWS_TP_RETURN_FINISHED|Task has finished, successfully as far as it goes
127 LWS_TP_RETURN_STOPPED|Task has finished, aborting in response to a request to stop
130 applied to it, which indicates to threadpool that this task wishes to remain
131 unstopped after the wsi closes.  This is useful in the case where the task
134 the task.  The task can then be monitored separately by using the token.
138 The task can choose to "SYNC" with the lws service thread, in other words
141 `lws_threadpool_task_sync()` to resume the task.
143 This is typically used when, eg, the task has filled its buffer, or ringbuffer,
148 sent with `lws_write()` and then `lws_threadpool_task_sync()` to allow the task
151 If the WRITABLE callback determines that the task should stop, it can just call
152 `lws_threadpool_task_sync()` with the second argument as 1, to force the task
157 When a finished task is reaped, or a task that become detached from its initial
159 task creation args struct to free anything related to the user pointer.
161 With threadpool, responsibility for freeing allocations used by the task belongs
162 strictly with the task, via the `.cleanup` function, once the task has been
164 wsi lifecycle controls deallocation.  This reflects the fact that the task
169 Care should be taken than data prepared by the task thread in the user priv
173 Task execution and the SYNC writable callbacks are mutually exclusive, so there
174 is no danger of collision between the task thread and the lws service thread if
175 the reason for the callback is a SYNC operation from the task thread.