summaryrefslogtreecommitdiff
path: root/src/qcam/assets/feathericons/arrow-right-circle.svg
diff options
context:
space:
mode:
authorLaurent Pinchart <laurent.pinchart@ideasonboard.com>2022-06-21 22:47:53 +0300
committerLaurent Pinchart <laurent.pinchart@ideasonboard.com>2022-07-04 23:08:12 +0300
commitb3fd8e14b52b5a42aca3c7dadca064b95cf19758 (patch)
treea206e837a8e3defd2151ff657e5c60b05621a272 /src/qcam/assets/feathericons/arrow-right-circle.svg
parent29ef923877c6eea202ad9f8ab39d219a8a953188 (diff)
gstreamer: Fix race conditions in task pause/resume
The task run function races with two other threads that want to resume the task: the requestCompleted() handler and the buffer-notify signal handler. If the former queues completed requests or the latter queues back buffers to the pool, and then resume the task, after the task run handler checks the queues but before it attemps to pause the task, then the task may be paused without noticing that more work is available. The most immediate way to fix this is to take the stream_lock in the requestCompleted() and buffer-notify signal handlers, or cover the whole task run handler with the GstLibcameraSrcState lock. This could cause long delays in the requestCompleted() handler, so that's not a good option. Instead, pause the task unconditionally at the beginning of its run function, and track while processing buffers and requests if the task needs to be resumed. It may also get resumed externally by the buffer-notify signal handler or the request completion handler, which are guaranteed not to race due to the lock taken by the gst_task_pause() and gst_task_resume() functions. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Diffstat (limited to 'src/qcam/assets/feathericons/arrow-right-circle.svg')
0 files changed, 0 insertions, 0 deletions