summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLaurent Pinchart <laurent.pinchart@ideasonboard.com>2021-05-22 00:17:23 +0300
committerLaurent Pinchart <laurent.pinchart@ideasonboard.com>2021-05-24 12:27:17 +0300
commitcccb74800012899baf85926e2e73b8bd790ecacb (patch)
tree44be0a5ab7f23d3b9e3d65f66790faaf65ac2ee0
parent6551bd39f047acaba269df17281b9b9c2a12581b (diff)
libcamera: thread: Drop doc of asynchronous signals delivery to applications
The asynchronous signal delivery mechanism can't be used by application, as it requires libcamera to be aware of the application event loop, which has been dropped a long time ago. Drop the corresponding documentation paragraph. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
-rw-r--r--src/libcamera/thread.cpp8
1 files changed, 0 insertions, 8 deletions
diff --git a/src/libcamera/thread.cpp b/src/libcamera/thread.cpp
index bc1dcede..d59e4396 100644
--- a/src/libcamera/thread.cpp
+++ b/src/libcamera/thread.cpp
@@ -64,14 +64,6 @@
* be overridden by selecting a different connection type when calling
* Signal::connect().
*
- * Asynchronous signal delivery is used internally in libcamera, but is also
- * available to applications if desired. To use this feature, applications
- * shall create receiver classes that inherit from the Object class, and
- * provide an event loop to the CameraManager as explained above. Note that
- * Object instances created by the application are limited to living in the
- * application's main thread. Creating Object instances from another thread of
- * an application causes undefined behaviour.
- *
* \section thread-reentrancy Reentrancy and Thread-Safety
*
* Through the documentation, several terms are used to define how classes and