<div dir="ltr"><div dir="ltr">Hi Laurent, thank you for the patch.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 24, 2021 at 12:44 PM Laurent Pinchart <<a href="mailto:laurent.pinchart@ideasonboard.com">laurent.pinchart@ideasonboard.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Umang,<br>
<br>
On Mon, May 24, 2021 at 08:47:00AM +0530, Umang Jain wrote:<br>
> Hi Laurent,<br>
> <br>
> Thanks for the work.<br>
> <br>
> Great to read the contexts for message deliveries you have mentioned. <br>
> However, how does one decide whether they need to ensure message <br>
> delivery before exit() ? What would be the applicable use-cases to that <br>
> context? (Just curious)<br>
<br>
It depends if the user of the thread needs a guarantee that all messages<br>
will be processed. That doesn't really answer your question...<br>
<br>
Let's take a practical example, posting post-processing work to a thread<br>
(which we should do quite soon, JPEG compression in the request<br>
completion handler isn't a good idea). When stopping the camera (HAL<br>
.close() or .flush()), if the HAL required for proper operation that the<br>
thread reports completion of all post-processing requests, then we'd<br>
need to ensure message delivery. On the other hand, the HAL could also<br>
stop the thread, and then look into its own queue of requests that are<br>
waiting for post-processing. Any request in that queue would then be<br>
considered as cancelled are reported as such to the camera service. In<br>
that case, we wouldn't require the thread to process all posted<br>
messages.<br>
<br>
> On 5/23/21 8:01 AM, Laurent Pinchart wrote:<br>
> > When a thread stops, messages may be left in its message queue. Document<br>
> > this in details, with a way to force processing of pending messages when<br>
> > the thread is stopped.<br>
> ><br>
> > Signed-off-by: Laurent Pinchart <<a href="mailto:laurent.pinchart@ideasonboard.com" target="_blank">laurent.pinchart@ideasonboard.com</a>><br>
><br>
> Reviewed-by: Umang Jain <<a href="mailto:umang.jain@ideasonboard.com" target="_blank">umang.jain@ideasonboard.com</a>><br>
><br></blockquote><div><br></div><div>Reviewed-by: Hirokazu Honda <<a href="mailto:hiroh@chromium.org">hiroh@chromium.org</a>></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> > ---<br>
> > src/libcamera/object.cpp | 8 ++++++++<br>
> > src/libcamera/thread.cpp | 44 ++++++++++++++++++++++++++++++++++++++++<br>
> > 2 files changed, 52 insertions(+)<br>
> ><br>
> > diff --git a/src/libcamera/object.cpp b/src/libcamera/object.cpp<br>
> > index cd83c684b989..5e6b73f9af84 100644<br>
> > --- a/src/libcamera/object.cpp<br>
> > +++ b/src/libcamera/object.cpp<br>
> > @@ -155,6 +155,10 @@ void Object::deleteLater()<br>
> > * running its event loop the message will not be delivered until the event<br>
> > * loop gets started.<br>
> > *<br>
> > + * Due to their asynchronous nature, threads do not provide any guarantee that<br>
> > + * all posted messages are delivered before the thread is stopped. See<br>
> > + * \ref thread-stop for additional information.<br>
> > + *<br>
> > * \context This function is \threadsafe.<br>
> > */<br>
> > void Object::postMessage(std::unique_ptr<Message> msg)<br>
> > @@ -212,6 +216,10 @@ void Object::message(Message *msg)<br>
> > * are passed untouched. The caller shall ensure that any pointer argument<br>
> > * remains valid until the method is invoked.<br>
> > *<br>
> > + * Due to the asynchronous nature of threads, functions invoked asynchronously<br>
> > + * with the ConnectionTypeQueued type are not guaranteed to be called before<br>
> > + * the thread is stopped. See \ref thread-stop for additional information.<br>
> > + *<br>
> > * \context This function is \threadsafe.<br>
> > *<br>
> > * \return For connection types ConnectionTypeDirect and<br>
> > diff --git a/src/libcamera/thread.cpp b/src/libcamera/thread.cpp<br>
> > index d59e43966d26..91e4737ad032 100644<br>
> > --- a/src/libcamera/thread.cpp<br>
> > +++ b/src/libcamera/thread.cpp<br>
> > @@ -221,6 +221,47 @@ ThreadData *ThreadData::current()<br>
> > * called. The event loop dispatches events (messages, notifiers and timers)<br>
> > * sent to the objects living in the thread. This behaviour can be modified by<br>
> > * overriding the run() function.<br>
> > + *<br>
> > + * \section thread-stop Stopping Threads<br>
> > + *<br>
> > + * Threads can't be forcibly stopped. Instead, a thread user first requests the<br>
> > + * thread to exit and then waits for the thread's main function to react to the<br>
> > + * request and return, at which points the thread will stop.<br>
> > + *<br>
> > + * For threads running exec(), the exit() function is used to request the thread<br>
> > + * to exit. For threads subclassing the Thread class and implementing a custom<br>
> > + * run() function, a subclass-specific mechanism shall be provided. In either<br>
> > + * case, the wait() function shall be called to wait for the thread to stop.<br>
> > + *<br>
> > + * Due to their asynchronous nature, threads are subject to race conditions when<br>
> > + * they stop. This is of particular importance for messages posted to the thread<br>
> > + * with postMessage() (and the other mechanisms that rely on it, such as<br>
> > + * Object::invokeMethod() or asynchronous signal delivery). To understand the<br>
> > + * issues, three contexts need to be considered:<br>
> > + *<br>
> > + * - The worker is the Thread performing work and being instructed to stop.<br>
> > + * - The controller is the context which instructs the worker thread to stop.<br>
> > + * - The other contexts are any threads other than the worker and controller<br>
> > + * that interact with the worker thread.<br>
> > + *<br>
> > + * Messages posted to the worker thread from the controller context before<br>
> > + * calling exit() are queued to the thread's message queue, and the Thread class<br>
> > + * offers no guarantee that those messages will be processed before the thread<br>
> > + * stops. This allows threads to stop fast.<br>
> > + *<br>
> > + * A thread that requires delivery of messages posted from the controller<br>
> > + * context before exit() should reimplement the run() function and call<br>
> > + * dispatchMessages() after exec().<br>
> > + *<br>
> > + * Messages posted to the worker thread from the other contexts are asynchronous<br>
> > + * with respect to the exit() call from the controller context. There is no<br>
> > + * guarantee as to whether those messages will be processed or not before the<br>
> > + * thread stops.<br>
> > + *<br>
> > + * Messages that are not processed will stay in the queue, in the exact same way<br>
> > + * as messages posted after the thread has stopped. They will be processed when<br>
> > + * the thread is restarted. If the thread is never restarted, they will be<br>
> > + * deleted without being processed when the Thread instance is destroyed.<br>
> > */<br>
> > <br>
> > /**<br>
> > @@ -480,6 +521,9 @@ EventDispatcher *Thread::eventDispatcher()<br>
> > * running its event loop the message will not be delivered until the event<br>
> > * loop gets started.<br>
> > *<br>
> > + * When the thread is stopped, posted messages may not have all been processed.<br>
> > + * See \ref thread-stop for additional information.<br>
> > + *<br>
> > * If the \a receiver is not bound to this thread the behaviour is undefined.<br>
> > *<br>
> > * \sa exec()<br>
<br>
-- <br>
Regards,<br>
<br>
Laurent Pinchart<br>
</blockquote></div></div>