| Message ID | 20210523023155.20268-4-laurent.pinchart@ideasonboard.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series |
|
| Related | show |
Hi Laurent, Thanks for your work. On 2021-05-23 05:31:54 +0300, Laurent Pinchart wrote: > 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> > --- > src/libcamera/thread.cpp | 8 -------- > 1 file changed, 8 deletions(-) > > diff --git a/src/libcamera/thread.cpp b/src/libcamera/thread.cpp > index bc1dcedea0d1..d59e43966d26 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 > -- > Regards, > > Laurent Pinchart >
Hi Laurent, On 5/23/21 8:01 AM, Laurent Pinchart wrote: > 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: Umang Jain <umang.jain@ideasonboard.com> > --- > src/libcamera/thread.cpp | 8 -------- > 1 file changed, 8 deletions(-) > > diff --git a/src/libcamera/thread.cpp b/src/libcamera/thread.cpp > index bc1dcedea0d1..d59e43966d26 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
Hi Laurent, thank you for the patch, On Mon, May 24, 2021 at 11:44 AM Umang Jain <umang.jain@ideasonboard.com> wrote: > Hi Laurent, > > On 5/23/21 8:01 AM, Laurent Pinchart wrote: > > 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: Umang Jain <umang.jain@ideasonboard.com> > Reviewed-by: Hirokazu Honda <hiroh@chromium.org> > > --- > > src/libcamera/thread.cpp | 8 -------- > > 1 file changed, 8 deletions(-) > > > > diff --git a/src/libcamera/thread.cpp b/src/libcamera/thread.cpp > > index bc1dcedea0d1..d59e43966d26 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 > >
Hi Laurent, On Sun, May 23, 2021 at 05:31:54AM +0300, Laurent Pinchart wrote: > 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. Are they still available internally to libcamera, don't they ? Would you like to drop the whole paragraph or only the 'available to applications.. ' part ? > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > --- > src/libcamera/thread.cpp | 8 -------- > 1 file changed, 8 deletions(-) > > diff --git a/src/libcamera/thread.cpp b/src/libcamera/thread.cpp > index bc1dcedea0d1..d59e43966d26 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 > -- > Regards, > > Laurent Pinchart >
Hi Jacopo, On Mon, May 24, 2021 at 10:55:35AM +0200, Jacopo Mondi wrote: > On Sun, May 23, 2021 at 05:31:54AM +0300, Laurent Pinchart wrote: > > 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. > > Are they still available internally to libcamera, don't they ? > > Would you like to drop the whole paragraph or only the 'available to > applications.. ' part ? If I remove the parts related to applications, the only remaining text would be * Asynchronous signal delivery is used internally in libcamera. Iit should be expected that libcamera's features are used by libcamera :-) I don't think this sentence would be very useful. > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > --- > > src/libcamera/thread.cpp | 8 -------- > > 1 file changed, 8 deletions(-) > > > > diff --git a/src/libcamera/thread.cpp b/src/libcamera/thread.cpp > > index bc1dcedea0d1..d59e43966d26 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
diff --git a/src/libcamera/thread.cpp b/src/libcamera/thread.cpp index bc1dcedea0d1..d59e43966d26 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
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> --- src/libcamera/thread.cpp | 8 -------- 1 file changed, 8 deletions(-)