From nobody Wed May 14 18:34:42 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1519227347901306.1141137152081; Wed, 21 Feb 2018 07:35:47 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 83DEEC05E75B; Wed, 21 Feb 2018 15:35:46 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4DF9A600D3; Wed, 21 Feb 2018 15:35:46 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id D0944181A87D; Wed, 21 Feb 2018 15:35:45 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id w1LFZZBF020944 for ; Wed, 21 Feb 2018 10:35:35 -0500 Received: by smtp.corp.redhat.com (Postfix) id 5AB2710A9713; Wed, 21 Feb 2018 15:35:35 +0000 (UTC) Received: from t460.redhat.com (unknown [10.33.36.87]) by smtp.corp.redhat.com (Postfix) with ESMTP id B1D3010A9711; Wed, 21 Feb 2018 15:35:34 +0000 (UTC) From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: libvir-list@redhat.com Date: Wed, 21 Feb 2018 15:35:19 +0000 Message-Id: <20180221153525.14973-5-berrange@redhat.com> In-Reply-To: <20180221153525.14973-1-berrange@redhat.com> References: <20180221153525.14973-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH 04/10] daemon: remove obsolete doc describing daemon threading X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 21 Feb 2018 15:35:47 +0000 (UTC) X-ZohoMail: RSF_0 Z_629925259 SPT_0 The THREADS.txt describes the way threading worked in libvirtd many many years ago, long before even the RPC code was modularized. Things have evolved significantly since then, so delete this potentially misleading doc. Signed-off-by: Daniel P. Berrang=C3=A9 --- daemon/THREADS.txt | 52 --------------------------------------------------= -- 1 file changed, 52 deletions(-) delete mode 100644 daemon/THREADS.txt diff --git a/daemon/THREADS.txt b/daemon/THREADS.txt deleted file mode 100644 index ae4e9bad90..0000000000 --- a/daemon/THREADS.txt +++ /dev/null @@ -1,52 +0,0 @@ - - Threading in the libvirtd daemon - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D - -To allow efficient processing of RPC requests, the libvirtd daemon -makes use of threads. - - - The process leader. This is the initial thread of control - when the daemon starts running. It is responsible for - initializing all the state, and starting the event loop. - Once that's all done, this thread does nothing except - wait for the event loop to quit, thus indicating an orderly - shutdown is required. - - - The event loop. This thread runs the event loop, sitting - in poll() on all monitored file handles, and calculating - and dispatching any timers that may be registered. When - this thread quits, the entire daemon will shutdown. - - - The workers. These 'n' threads all sit around waiting to - process incoming RPC requests. Since RPC requests may take - a long time to complete, with long idle periods, there will - be quite a few workers running. - -The use of threads obviously requires locking to ensure safety when -accessing/changing data structures. - - - the top level lock is on 'struct qemud_server'. This must be - held before acquiring any other lock - - - Each 'struct qemud_client' object has a lock. The server lock - must be held before acquiring it. Once the client lock is acquired - the server lock can (optionally) be dropped. - - - The event loop has its own self-contained lock. You can ignore - this as a caller of virEvent APIs. - - -The server lock is used in conjunction with a condition variable -to pass jobs from the event loop thread to the workers. The main -event loop thread handles I/O from the client socket, and once a -complete RPC message has been read off the wire (and optionally -decrypted), it will be placed on the 'dx' job queue for the -associated client object. The job condition will be signalled and -a worker will wakeup and process it. - -The worker thread must quickly drop its locks on the server and -client to allow the main event loop thread to continue running -with its other work. Critically important, is that now libvirt -API call will ever be made with the server or client locks held. - --- End --=20 2.14.3 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list