[{"id":14618,"web_url":"https://patchwork.libcamera.org/comment/14618/","msgid":"","date":"2021-01-20T03:56:46","subject":"Re: [libcamera-devel] [PATCH v2] cam: event_loop: Stop processing\n\tcalls when event loop is exiting","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Ni Niklas,\n\nThank you for the patch.\n\nOn Wed, Jan 20, 2021 at 12:33:15AM +0100, Niklas Söderlund wrote:\n> Terminating the event loop with EventLoop::exit() does not grantee that\n> it will terminate. If the event loops 'call later' queue can be kept\n> non-empty by continuously queuing new calls using EventLoop::callLater()\n> either from a different thread or from callbacks in the loop itself\n> EventLoop::dispatchCalls() will never complete and the loop will run\n> forever.\n> \n> Solve this by evaluating the exit condition between each callback and\n> only enter the idle loop if there are no callbacks to process.\n> \n> Reported-by: Sebastian Fricke \n> Fixes: f49e93338b6309a6 (\"cam: event_loop: Add deferred calls support\")\n> Signed-off-by: Niklas Söderlund \n\nThis seems to be even more of a hack than the previous version :-( Can\nwe fix this properly please ?\n\n> ---\n> * Changes since v1\n> - Was [PATCH 0/2] cam: Fix races in event loop and long request\n> processing times\n> - Rework dispatchCalls() instead of callLater() for a simpler fix.\n> ---\n> src/cam/event_loop.cpp | 22 +++++++++++++---------\n> src/cam/event_loop.h | 2 +-\n> 2 files changed, 14 insertions(+), 10 deletions(-)\n> \n> diff --git a/src/cam/event_loop.cpp b/src/cam/event_loop.cpp\n> index 94c5d1d362455f33..18786b4500be9b6f 100644\n> --- a/src/cam/event_loop.cpp\n> +++ b/src/cam/event_loop.cpp\n> @@ -41,7 +41,9 @@ int EventLoop::exec()\n> \texit_.store(false, std::memory_order_release);\n> \n> \twhile (!exit_.load(std::memory_order_acquire)) {\n> -\t\tdispatchCalls();\n> +\t\tif (dispatchCall())\n> +\t\t\tcontinue;\n> +\n> \t\tevent_base_loop(event_, EVLOOP_NO_EXIT_ON_EMPTY);\n> \t}\n> \n> @@ -70,17 +72,19 @@ void EventLoop::callLater(const std::function &func)\n> \tinterrupt();\n> }\n> \n> -void EventLoop::dispatchCalls()\n> +bool EventLoop::dispatchCall()\n> {\n> \tstd::unique_lock locker(lock_);\n> \n> -\tfor (auto iter = calls_.begin(); iter != calls_.end(); ) {\n> -\t\tstd::function call = std::move(*iter);\n> +\tif (calls_.empty())\n> +\t\treturn false;\n> \n> -\t\titer = calls_.erase(iter);\n> +\tauto iter = calls_.begin();\n> +\tstd::function call = std::move(*iter);\n> +\tcalls_.erase(iter);\n> \n> -\t\tlocker.unlock();\n> -\t\tcall();\n> -\t\tlocker.lock();\n> -\t}\n> +\tlocker.unlock();\n> +\tcall();\n> +\n> +\treturn true;\n> }\n> diff --git a/src/cam/event_loop.h b/src/cam/event_loop.h\n> index 408073c50594d09d..b84e1c9e432086e3 100644\n> --- a/src/cam/event_loop.h\n> +++ b/src/cam/event_loop.h\n> @@ -38,7 +38,7 @@ private:\n> \tstd::mutex lock_;\n> \n> \tvoid interrupt();\n> -\tvoid dispatchCalls();\n> +\tbool dispatchCall();\n> };\n> \n> #endif /* __CAM_EVENT_LOOP_H__ */","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id E2105BD808\n\tfor ;\n\tWed, 20 Jan 2021 03:57:06 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 6076C68173;\n\tWed, 20 Jan 2021 04:57:06 +0100 (CET)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 967B56010B\n\tfor ;\n\tWed, 20 Jan 2021 04:57:04 +0100 (CET)","from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi\n\t[62.78.145.57])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 1EAF1813;\n\tWed, 20 Jan 2021 04:57:04 +0100 (CET)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"rqc/lJZB\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1611115024;\n\tbh=i1daW99r6hO4CHqroVOIXTjcw2oeQAlMwiVt40kXyUs=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=rqc/lJZBKkigNFb6VoiTGJQdah7tQrARnZF6O82w/fl07ljjnkgoqGUmHDFvdtIyM\n\t6/sRdHJBlhqTcdOAFJZTNV2IMPzKa+IGT6Xk0Z4ocHmRWRQTulIE5EmMiyvFHg6/gs\n\tmRxzAIqInRPQUp/7YqbB+OYdi/voOGBkZY+2MC8M=","Date":"Wed, 20 Jan 2021 05:56:46 +0200","From":"Laurent Pinchart ","To":"Niklas =?utf-8?q?S=C3=B6derlund?= ","Message-ID":"","References":"<20210119233315.3305649-1-niklas.soderlund@ragnatech.se>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20210119233315.3305649-1-niklas.soderlund@ragnatech.se>","Subject":"Re: [libcamera-devel] [PATCH v2] cam: event_loop: Stop processing\n\tcalls when event loop is exiting","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":14619,"web_url":"https://patchwork.libcamera.org/comment/14619/","msgid":"","date":"2021-01-20T09:12:49","subject":"Re: [libcamera-devel] [PATCH v2] cam: event_loop: Stop processing\n\tcalls when event loop is exiting","submitter":{"id":5,"url":"https://patchwork.libcamera.org/api/people/5/","name":"Niklas Söderlund","email":"niklas.soderlund@ragnatech.se"},"content":"Hi Laurent,\n\nThanks for your feedback.\n\nOn 2021-01-20 05:56:46 +0200, Laurent Pinchart wrote:\n> Ni Niklas,\n> \n> Thank you for the patch.\n> \n> On Wed, Jan 20, 2021 at 12:33:15AM +0100, Niklas Söderlund wrote:\n> > Terminating the event loop with EventLoop::exit() does not grantee that\n> > it will terminate. If the event loops 'call later' queue can be kept\n> > non-empty by continuously queuing new calls using EventLoop::callLater()\n> > either from a different thread or from callbacks in the loop itself\n> > EventLoop::dispatchCalls() will never complete and the loop will run\n> > forever.\n> > \n> > Solve this by evaluating the exit condition between each callback and\n> > only enter the idle loop if there are no callbacks to process.\n> > \n> > Reported-by: Sebastian Fricke \n> > Fixes: f49e93338b6309a6 (\"cam: event_loop: Add deferred calls support\")\n> > Signed-off-by: Niklas Söderlund \n> \n> This seems to be even more of a hack than the previous version :-( Can\n> we fix this properly please ?\n\nI would like noting more then to fix this properly.\n\nThe heart of the problem is that some of our pipelines require more then \nN requests to be queued for it to complete N. I agree it's bad that our \npipelines behaves differently and something should be done to align \nthem.\n\nIt feels natural that such work would be paired with a compliance tool \nso situations like this can be detected early and avoided. I have been \ntempted many times to start a compliance tool but have postponed it. My \nprimary reason for doing so is that we never really defined the number \nof requests queued vs. pipeline depth and pipeline stalls and what a \ncorrect behavior in such situations is. I was pleased with the camera \nmodel work had was hoping it would lead to a more strict definition wich \nsuch tools could be built upon.\n\nHow ever solving the core problem is a rather large task to sort out. \nHow can we handle the issue in the short time frame? No matter how I \ndice it I see a hack in cam is needed ;-(\n\n- The best option I see is to use the 'process call in batches' solution\n as your suggestion in v1 and then either remove support for \n --capture=N or accept that on \"broken\" pipelines N+pipeline depth \n frames will be processed, but at least cam won't deadlock.\n\n- Another other option (that I really don't like) is to revert the \n deferred calls support.\n\n- We can also fix this properly in cam by only queuing N requests and \n expecting N requests to complete. This will break --capture=N on some \n pipelines, but perhaps that is the pressure we need to push the fix \n upwards.\n\n> \n> > ---\n> > * Changes since v1\n> > - Was [PATCH 0/2] cam: Fix races in event loop and long request\n> > processing times\n> > - Rework dispatchCalls() instead of callLater() for a simpler fix.\n> > ---\n> > src/cam/event_loop.cpp | 22 +++++++++++++---------\n> > src/cam/event_loop.h | 2 +-\n> > 2 files changed, 14 insertions(+), 10 deletions(-)\n> > \n> > diff --git a/src/cam/event_loop.cpp b/src/cam/event_loop.cpp\n> > index 94c5d1d362455f33..18786b4500be9b6f 100644\n> > --- a/src/cam/event_loop.cpp\n> > +++ b/src/cam/event_loop.cpp\n> > @@ -41,7 +41,9 @@ int EventLoop::exec()\n> > \texit_.store(false, std::memory_order_release);\n> > \n> > \twhile (!exit_.load(std::memory_order_acquire)) {\n> > -\t\tdispatchCalls();\n> > +\t\tif (dispatchCall())\n> > +\t\t\tcontinue;\n> > +\n> > \t\tevent_base_loop(event_, EVLOOP_NO_EXIT_ON_EMPTY);\n> > \t}\n> > \n> > @@ -70,17 +72,19 @@ void EventLoop::callLater(const std::function &func)\n> > \tinterrupt();\n> > }\n> > \n> > -void EventLoop::dispatchCalls()\n> > +bool EventLoop::dispatchCall()\n> > {\n> > \tstd::unique_lock locker(lock_);\n> > \n> > -\tfor (auto iter = calls_.begin(); iter != calls_.end(); ) {\n> > -\t\tstd::function call = std::move(*iter);\n> > +\tif (calls_.empty())\n> > +\t\treturn false;\n> > \n> > -\t\titer = calls_.erase(iter);\n> > +\tauto iter = calls_.begin();\n> > +\tstd::function call = std::move(*iter);\n> > +\tcalls_.erase(iter);\n> > \n> > -\t\tlocker.unlock();\n> > -\t\tcall();\n> > -\t\tlocker.lock();\n> > -\t}\n> > +\tlocker.unlock();\n> > +\tcall();\n> > +\n> > +\treturn true;\n> > }\n> > diff --git a/src/cam/event_loop.h b/src/cam/event_loop.h\n> > index 408073c50594d09d..b84e1c9e432086e3 100644\n> > --- a/src/cam/event_loop.h\n> > +++ b/src/cam/event_loop.h\n> > @@ -38,7 +38,7 @@ private:\n> > \tstd::mutex lock_;\n> > \n> > \tvoid interrupt();\n> > -\tvoid dispatchCalls();\n> > +\tbool dispatchCall();\n> > };\n> > \n> > #endif /* __CAM_EVENT_LOOP_H__ */\n> \n> -- \n> Regards,\n> \n> Laurent Pinchart","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id A9A93BD808\n\tfor ;\n\tWed, 20 Jan 2021 09:12:53 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 6A5326817C;\n\tWed, 20 Jan 2021 10:12:53 +0100 (CET)","from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com\n\t[IPv6:2a00:1450:4864:20::22a])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 9B7E568177\n\tfor ;\n\tWed, 20 Jan 2021 10:12:51 +0100 (CET)","by mail-lj1-x22a.google.com with SMTP id x23so25153994lji.7\n\tfor ;\n\tWed, 20 Jan 2021 01:12:51 -0800 (PST)","from localhost (h-209-203.A463.priv.bahnhof.se. [155.4.209.203])\n\tby smtp.gmail.com with ESMTPSA id\n\t24sm109701lju.113.2021.01.20.01.12.49\n\t(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n\tWed, 20 Jan 2021 01:12:50 -0800 (PST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=ragnatech-se.20150623.gappssmtp.com\n\theader.i=@ragnatech-se.20150623.gappssmtp.com\n\theader.b=\"CqKX32++\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=ragnatech-se.20150623.gappssmtp.com; s=20150623;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:content-transfer-encoding:in-reply-to;\n\tbh=ArNJlN0PVAWzvDF1btjsHlnbmm29JVuvPVVvNAfIEeY=;\n\tb=CqKX32++2uoWHJqUITYEx/++xnc1Zw4gCn5OKOSBXyXJ0Z2BZIzeT6/NZWQKLKHJ1t\n\tIwaK3120RE14kiXtrf3tODApNTNOlLc5Ng+pbF6lVKOSHuvhfFZ3i3+Favt3VwmtG6+i\n\tnFZACfYwoJ+rMxH5db/7MUulWQnN/DkXHRTkKOFT3LrkP1ZRfvlo2Y1i6kk42949d+ip\n\t1yzm6F4TH8r9JwStBx7cXg2m3ztMUFNMJ1Iw24lkfwVYwiiXB3OAI+Wq0k3Z8HaVHKis\n\tYjpm5cvaze66PM7IUem2PkVeqavViklZz3gcBJdVC6zPqtSqKTdnkiIgIj4twyxJM020\n\tPICA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:content-transfer-encoding\n\t:in-reply-to;\n\tbh=ArNJlN0PVAWzvDF1btjsHlnbmm29JVuvPVVvNAfIEeY=;\n\tb=R03usVyWce+JBrptL1NBapEuxrIyafwbj/6KZi/TfXk1+adihTh565J78gJdpCYwIE\n\ttgUTkMsjA9uDKN2dySl3N6HO0IfPsVKX2CpMIV2pU/vV+LVKfi+wt3aovvcgOjWWO4o4\n\tzvYWAERAxwWpK5HPoW/gbSXHZS5U7tyMbZ2lAE2n0fn9xP7kKI4y+py95p9oXCVqxXoa\n\tNLaRNQtavShxrVcYGqjdgZgNwRfbkUE2sZtsyHsMAcDUCDcg7l9jG2uJnpbfnwsiGUIO\n\tYcQ7MSmu43uAMFeDQyHnpA6rBcqo4Hb7cyjCxDqWPMZn8vmB7f47gs/dnJ/J5pcrexJG\n\tDBxg==","X-Gm-Message-State":"AOAM5337e0T3akf6TOzoIChqmFVkrbeVJWlxfCH6C2XyNBSm3E93F+vg\n\tKeF9WJkQiwB04TgF9U2zUxD97Q==","X-Google-Smtp-Source":"ABdhPJwmIQxYcjbZihpG/qgfK1SoPCBD4whVTTvYgF8qQ4RDS6wsjc9OL9ZHifa+MhKyOR36REoUUw==","X-Received":"by 2002:a05:651c:211e:: with SMTP id\n\ta30mr3951978ljq.108.1611133970804; \n\tWed, 20 Jan 2021 01:12:50 -0800 (PST)","Date":"Wed, 20 Jan 2021 10:12:49 +0100","From":"Niklas =?iso-8859-1?q?S=F6derlund?= ","To":"Laurent Pinchart ","Message-ID":"","References":"<20210119233315.3305649-1-niklas.soderlund@ragnatech.se>\n\t","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"","Subject":"Re: [libcamera-devel] [PATCH v2] cam: event_loop: Stop processing\n\tcalls when event loop is exiting","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org","Content-Type":"text/plain; charset=\"iso-8859-1\"","Content-Transfer-Encoding":"quoted-printable","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":14628,"web_url":"https://patchwork.libcamera.org/comment/14628/","msgid":"<20210120102921.l3veznjdhfapye4e@basti-TUXEDO-Book-XA1510>","date":"2021-01-20T10:29:21","subject":"Re: [libcamera-devel] [PATCH v2] cam: event_loop: Stop processing\n\tcalls when event loop is exiting","submitter":{"id":78,"url":"https://patchwork.libcamera.org/api/people/78/","name":"Sebastian Fricke","email":"sebastian.fricke@posteo.net"},"content":"Hey Niklas & Laurent,\n\nOn 20.01.2021 10:12, Niklas Söderlund wrote:\n>Hi Laurent,\n>\n>Thanks for your feedback.\n>\n>On 2021-01-20 05:56:46 +0200, Laurent Pinchart wrote:\n>> Ni Niklas,\n>>\n>> Thank you for the patch.\n>>\n>> On Wed, Jan 20, 2021 at 12:33:15AM +0100, Niklas Söderlund wrote:\n>> > Terminating the event loop with EventLoop::exit() does not grantee that\n>> > it will terminate. If the event loops 'call later' queue can be kept\n>> > non-empty by continuously queuing new calls using EventLoop::callLater()\n>> > either from a different thread or from callbacks in the loop itself\n>> > EventLoop::dispatchCalls() will never complete and the loop will run\n>> > forever.\n>> >\n>> > Solve this by evaluating the exit condition between each callback and\n>> > only enter the idle loop if there are no callbacks to process.\n>> >\n>> > Reported-by: Sebastian Fricke \n>> > Fixes: f49e93338b6309a6 (\"cam: event_loop: Add deferred calls support\")\n>> > Signed-off-by: Niklas Söderlund \n>>\n>> This seems to be even more of a hack than the previous version :-( Can\n>> we fix this properly please ?\n>\n>I would like noting more then to fix this properly.\n>\n>The heart of the problem is that some of our pipelines require more then\n>N requests to be queued for it to complete N. I agree it's bad that our\n>pipelines behaves differently and something should be done to align\n>them.\n>\n>It feels natural that such work would be paired with a compliance tool\n>so situations like this can be detected early and avoided. I have been\n>tempted many times to start a compliance tool but have postponed it. My\n\nI am currently looking for a follow up project to start within the next 2-3\nweeks. If you would like to we could talk about your idea and design, so\nthat I am able to start working on it, as soon as my current projects\nare finished.\n\n>primary reason for doing so is that we never really defined the number\n>of requests queued vs. pipeline depth and pipeline stalls and what a\n>correct behavior in such situations is. I was pleased with the camera\n>model work had was hoping it would lead to a more strict definition wich\n>such tools could be built upon.\n>\n>How ever solving the core problem is a rather large task to sort out.\n\nIf I understood your discussion correctly, then the sub-tasks of this\none 'bigger' task are:\n- Make sure that each pipeline requies exactly the expected amount of\n requests in order process the given amount of frames, by implementing\n a complience tool to check the pipelines.\n- Switch the behavior of the `cam` command to count the number of queued\n requests to the camera instead of the number of completed requests.\n\nWhich other tasks would you add to that list?\n\n>How can we handle the issue in the short time frame? No matter how I\n>dice it I see a hack in cam is needed ;-(\n>\n>- The best option I see is to use the 'process call in batches' solution\n> as your suggestion in v1 and then either remove support for\n> --capture=N or accept that on \"broken\" pipelines N+pipeline depth\n> frames will be processed, but at least cam won't deadlock.\n>\n>- Another other option (that I really don't like) is to revert the\n> deferred calls support.\n>\n>- We can also fix this properly in cam by only queuing N requests and\n> expecting N requests to complete. This will break --capture=N on some\n> pipelines, but perhaps that is the pressure we need to push the fix\n> upwards.\n\nI think I like the idea of starting out with the right behavior in the\nfirst place. Are there any cases known to you guys, where the `cam`\napplication is used for anything else than testing the libcamera project?\nLike is there anything that could actually \"break\"?\n\n>\n>>\n>> > ---\n>> > * Changes since v1\n>> > - Was [PATCH 0/2] cam: Fix races in event loop and long request\n>> > processing times\n>> > - Rework dispatchCalls() instead of callLater() for a simpler fix.\n>> > ---\n>> > src/cam/event_loop.cpp | 22 +++++++++++++---------\n>> > src/cam/event_loop.h | 2 +-\n>> > 2 files changed, 14 insertions(+), 10 deletions(-)\n>> >\n>> > diff --git a/src/cam/event_loop.cpp b/src/cam/event_loop.cpp\n>> > index 94c5d1d362455f33..18786b4500be9b6f 100644\n>> > --- a/src/cam/event_loop.cpp\n>> > +++ b/src/cam/event_loop.cpp\n>> > @@ -41,7 +41,9 @@ int EventLoop::exec()\n>> > \texit_.store(false, std::memory_order_release);\n>> >\n>> > \twhile (!exit_.load(std::memory_order_acquire)) {\n>> > -\t\tdispatchCalls();\n>> > +\t\tif (dispatchCall())\n>> > +\t\t\tcontinue;\n>> > +\n>> > \t\tevent_base_loop(event_, EVLOOP_NO_EXIT_ON_EMPTY);\n>> > \t}\n>> >\n>> > @@ -70,17 +72,19 @@ void EventLoop::callLater(const std::function &func)\n>> > \tinterrupt();\n>> > }\n>> >\n>> > -void EventLoop::dispatchCalls()\n>> > +bool EventLoop::dispatchCall()\n>> > {\n>> > \tstd::unique_lock locker(lock_);\n>> >\n>> > -\tfor (auto iter = calls_.begin(); iter != calls_.end(); ) {\n>> > -\t\tstd::function call = std::move(*iter);\n>> > +\tif (calls_.empty())\n>> > +\t\treturn false;\n>> >\n>> > -\t\titer = calls_.erase(iter);\n>> > +\tauto iter = calls_.begin();\n>> > +\tstd::function call = std::move(*iter);\n>> > +\tcalls_.erase(iter);\n>> >\n>> > -\t\tlocker.unlock();\n>> > -\t\tcall();\n>> > -\t\tlocker.lock();\n>> > -\t}\n>> > +\tlocker.unlock();\n>> > +\tcall();\n>> > +\n>> > +\treturn true;\n>> > }\n>> > diff --git a/src/cam/event_loop.h b/src/cam/event_loop.h\n>> > index 408073c50594d09d..b84e1c9e432086e3 100644\n>> > --- a/src/cam/event_loop.h\n>> > +++ b/src/cam/event_loop.h\n>> > @@ -38,7 +38,7 @@ private:\n>> > \tstd::mutex lock_;\n>> >\n>> > \tvoid interrupt();\n>> > -\tvoid dispatchCalls();\n>> > +\tbool dispatchCall();\n>> > };\n>> >\n>> > #endif /* __CAM_EVENT_LOOP_H__ */\n>>\n>> --\n>> Regards,\n>>\n>> Laurent Pinchart\n>\n>-- \n>Regards,\n>Niklas Söderlund\n\nGreetings,\nSebastian Fricke\n>_______________________________________________\n>libcamera-devel mailing list\n>libcamera-devel@lists.libcamera.org\n>https://lists.libcamera.org/listinfo/libcamera-devel","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 450CFC0F2A\n\tfor ;\n\tWed, 20 Jan 2021 10:29:26 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 15C0B68196;\n\tWed, 20 Jan 2021 11:29:26 +0100 (CET)","from mout02.posteo.de (mout02.posteo.de [185.67.36.66])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id C658568196\n\tfor ;\n\tWed, 20 Jan 2021 11:29:23 +0100 (CET)","from submission (posteo.de [89.146.220.130]) \n\tby mout02.posteo.de (Postfix) with ESMTPS id 44B012400FD\n\tfor ;\n\tWed, 20 Jan 2021 11:29:23 +0100 (CET)","from customer (localhost [127.0.0.1])\n\tby submission (posteo.de) with ESMTPSA id 4DLMFt4NGSz9rxS;\n\tWed, 20 Jan 2021 11:29:22 +0100 (CET)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=posteo.net header.i=@posteo.net\n\theader.b=\"fLBRxhjA\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;\n\tt=1611138563; bh=KEos0nE6+MYlwccLZlJ2OYMEcOxjUx9dTiy0iKH10zo=;\n\th=Date:From:To:Cc:Subject:From;\n\tb=fLBRxhjAI2hgLgKuzG+48xSCrvNSgE0LhFA8IPsXqYPzqOGnAvtthwEQM/MfkX+MR\n\tTNcOT9Q4nO07ZwgkikLZflZMqU83GOKXgwHFzwGSY88RVfJDBjBFDleULVIckcwmbt\n\tA3E8/632JRE4O3+gc+gAW7B4a1SPwio421NUhASecDplQwOvNCOaboPYYcHLK/sDSb\n\t1PETKTeVZqgpQS9Tj6Rp389L14j+P16RJiIFef7B0eSNRcdgJuk52pm7Lrz5gZ1wv3\n\tRo9C1q6hHjo+tLasBmoLfzFVTsuEpSIQzYYMXJMJIH3RP9DDv6WK67vZ1Eyr175LmY\n\td/ZJNDNQQjd2Q==","Date":"Wed, 20 Jan 2021 11:29:21 +0100","From":"Sebastian Fricke ","To":"Niklas =?utf-8?q?S=C3=B6derlund?= ","Message-ID":"<20210120102921.l3veznjdhfapye4e@basti-TUXEDO-Book-XA1510>","References":"<20210119233315.3305649-1-niklas.soderlund@ragnatech.se>\n\t\n\t","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"","Subject":"Re: [libcamera-devel] [PATCH v2] cam: event_loop: Stop processing\n\tcalls when event loop is exiting","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org","Content-Transfer-Encoding":"base64","Content-Type":"text/plain; charset=\"utf-8\"; Format=\"flowed\"","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}}]