From patchwork Sat Jan 30 00:19:13 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Niklas_S=C3=B6derlund?= X-Patchwork-Id: 11068 Return-Path: X-Original-To: parsemail@patchwork.libcamera.org Delivered-To: parsemail@patchwork.libcamera.org Received: from lancelot.ideasonboard.com (lancelot.ideasonboard.com [92.243.16.209]) by patchwork.libcamera.org (Postfix) with ESMTPS id DC289BD808 for ; Sat, 30 Jan 2021 00:19:39 +0000 (UTC) Received: from lancelot.ideasonboard.com (localhost [IPv6:::1]) by lancelot.ideasonboard.com (Postfix) with ESMTP id 3635F683C8; Sat, 30 Jan 2021 01:19:39 +0100 (CET) Received: from bin-mail-out-06.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id 1AA1A6030A for ; Sat, 30 Jan 2021 01:19:37 +0100 (CET) X-Halon-ID: d26ac818-6290-11eb-b73f-0050569116f7 Authorized-sender: niklas.soderlund@fsdn.se Received: from bismarck.berto.se (p4fca2458.dip0.t-ipconnect.de [79.202.36.88]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPA id d26ac818-6290-11eb-b73f-0050569116f7; Sat, 30 Jan 2021 01:19:35 +0100 (CET) From: =?utf-8?q?Niklas_S=C3=B6derlund?= To: libcamera-devel@lists.libcamera.org Date: Sat, 30 Jan 2021 01:19:13 +0100 Message-Id: <20210130001915.489703-1-niklas.soderlund@ragnatech.se> X-Mailer: git-send-email 2.30.0 MIME-Version: 1.0 Subject: [libcamera-devel] [PATCH v3 0/2] cam: Fix races in event loop and long request processing times X-BeenThere: libcamera-devel@lists.libcamera.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libcamera-devel-bounces@lists.libcamera.org Sender: "libcamera-devel" Hello, Using cam to writing requests to (slow) media sometimes lock cam in an unbreakable loop. At the heart of the problem is that when request processing was moved from the camera to the main thread subtle races in the cam event loop implementation where exposed. The races are easily trigged by having callbacks injected into the even loop that takes a long time to process. The only callbacks cam currently injects to the event loop are processing of completed requests. So by increasing there processing time by writing them to disk the races where trigged. This series fixes two different issues found when debugging this. Patch 1/2 solves a design issue in the event loop implementation where the callback queue can be flooded which prevents termination of the loop. While patch 2/2 solves a cam design issue where the --capture=N behavior of only capturing N requests where broken but hidden by the problem in patch 1/2. Niklas Söderlund (2): cam: event_loop: Stop queuing calls when the event loop are exiting cam: Only queue the exact number of requests asked for src/cam/capture.cpp | 16 +++++++++++++--- src/cam/capture.h | 2 ++ src/cam/event_loop.cpp | 21 +++++++++------------ src/cam/event_loop.h | 2 +- 4 files changed, 25 insertions(+), 16 deletions(-)