From patchwork Sun May 23 02:31:54 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Laurent Pinchart X-Patchwork-Id: 12366 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 C3CD9C3200 for ; Sun, 23 May 2021 02:32:06 +0000 (UTC) Received: from lancelot.ideasonboard.com (localhost [IPv6:::1]) by lancelot.ideasonboard.com (Postfix) with ESMTP id 6869D6891E; Sun, 23 May 2021 04:32:06 +0200 (CEST) Authentication-Results: lancelot.ideasonboard.com; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="Hc0Xmbbe"; dkim-atps=neutral Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id 703E368911 for ; Sun, 23 May 2021 04:32:02 +0200 (CEST) Received: from pendragon.lan (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id F35302A8; Sun, 23 May 2021 04:32:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1621737122; bh=4DX+fdAAjUoOjofw2CydUwhFYPlKi9X48/oFJfmcoM4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Hc0XmbbewOZSlZ9vX3FsgOpk+gvBoa8YOucq/K5kf45/SIAS9QhzzeNc0zWSfyPdI RWVSQ2bzWQSNGIEvOdtF/c8+2k/vA6xtNTWbBSu4Djj3CUKZPCsmEu/in5E7VaWK+k jMumh3aXqmAOoecjNiG3TXVeO8fpclav1g4v3TnM= From: Laurent Pinchart To: libcamera-devel@lists.libcamera.org Date: Sun, 23 May 2021 05:31:54 +0300 Message-Id: <20210523023155.20268-4-laurent.pinchart@ideasonboard.com> X-Mailer: git-send-email 2.28.1 In-Reply-To: <20210523023155.20268-1-laurent.pinchart@ideasonboard.com> References: <20210523023155.20268-1-laurent.pinchart@ideasonboard.com> MIME-Version: 1.0 Subject: [libcamera-devel] [PATCH 3/4] libcamera: thread: Drop doc of asynchronous signals delivery to applications 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" 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 Reviewed-by: Niklas Söderlund Reviewed-by: Umang Jain Reviewed-by: Hirokazu Honda --- 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