diff options
| author | Laurent Pinchart <laurent.pinchart@ideasonboard.com> | 2021-05-22 00:17:23 +0300 |
|---|---|---|
| committer | Laurent Pinchart <laurent.pinchart@ideasonboard.com> | 2021-05-24 12:27:17 +0300 |
| commit | cccb74800012899baf85926e2e73b8bd790ecacb (patch) | |
| tree | 44be0a5ab7f23d3b9e3d65f66790faaf65ac2ee0 | |
| parent | 6551bd39f047acaba269df17281b9b9c2a12581b (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.cpp | 8 |
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 |