summaryrefslogtreecommitdiff
path: root/test/media_device/media_device_acquire.cpp
diff options
context:
space:
mode:
authorLaurent Pinchart <laurent.pinchart@ideasonboard.com>2020-01-22 21:30:10 +0200
committerLaurent Pinchart <laurent.pinchart@ideasonboard.com>2020-02-13 12:34:35 +0200
commit1aa49db823870532adc52ecd6f405b13a4da29ec (patch)
tree3602b8c9b39cfff7e8b77482c443eb0d646226f5 /test/media_device/media_device_acquire.cpp
parent09c45cc1faa9805124168de414df7eba007acfee (diff)
libcamera: camera_manager: Run the camera manager in a thread
Relying on the application event loop to process all our internal events is a bad idea for multiple reasons. In many cases the user of libcamera can't provide an event loop, for instance when running through one of the adaptation layers. The Android camera HAL and V4L2 compatibility layer create a thread for this reason, and the GStreamer element would need to do so as well. Furthermore, relying on the application event loop pushes libcamera's realtime constraints to the application, which isn't manageable. For these reasons it's desirable to always run the camera manager, the pipeline handlers and the cameras in a separate thread. Doing so isn't too complicated, it only involves creating the thread internally when starting the camera manager, and synchronizing a few methods of the Camera class. Do so as a first step towards defining the threading model of libcamera. The event dispatcher interface is still exposed to applications, to enable cross-thread signal delivery if desired. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Diffstat (limited to 'test/media_device/media_device_acquire.cpp')
0 files changed, 0 insertions, 0 deletions