From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#57196: 28.1.90; An idea to allow background (low-priority) threads Date: Sun, 14 Aug 2022 16:37:12 +0300 Message-ID: <83tu6fj69j.fsf@gnu.org> References: <878rnr1n17.fsf@localhost> <83bksnl331.fsf@gnu.org> <87mtc7fea6.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15289"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 57196@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Aug 14 15:38:13 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oNDoj-0003pj-0D for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 14 Aug 2022 15:38:13 +0200 Original-Received: from localhost ([::1]:48666 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oNDog-0003WP-FM for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 14 Aug 2022 09:38:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38818) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oNDoY-0003Uk-9z for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2022 09:38:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46491) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oNDoY-0005PU-1Y for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2022 09:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oNDoX-0004Vy-OI for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2022 09:38:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 14 Aug 2022 13:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57196 X-GNU-PR-Package: emacs Original-Received: via spool by 57196-submit@debbugs.gnu.org id=B57196.166048425617313 (code B ref 57196); Sun, 14 Aug 2022 13:38:01 +0000 Original-Received: (at 57196) by debbugs.gnu.org; 14 Aug 2022 13:37:36 +0000 Original-Received: from localhost ([127.0.0.1]:36238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNDo7-0004VA-UO for submit@debbugs.gnu.org; Sun, 14 Aug 2022 09:37:36 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:54062) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNDo6-0004Uw-Al for 57196@debbugs.gnu.org; Sun, 14 Aug 2022 09:37:34 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45450) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oNDo1-0005NY-15; Sun, 14 Aug 2022 09:37:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Hk7FycCxhrdQgEgCLz2iAMGnU7hRB1taDxu2aH29BBw=; b=ED3qJxvGaiZe Or3OJerRKHj3B2amqblte9zlTndANg6C+6e0UTjuaWcsmx/laJ04cQ8ZYweyoWemsEymDEaVSQ3gr DLkJ/ie0cNr+Kye4F9KOpnzYmX2WS/pH8DV0/LPn37b3tnush+EHUD/TEv9bb86GGdB5GZV2t2zln 1XPAaV7O3xRreaolwsLbf1qAelRyTmNkDQZV/3ppLPKydct53VJPn48aUxUwkRmpbWaMP169lMEWf y53zpeWDVVSPs/QZ+G3KeunlzFE+tb6/5H1Ai1BAXcFgThkO7kFsLYirk8YsK6IJhe2vtLIMurswd 3N+r61xCgitEfyAGR+OGng==; Original-Received: from [87.69.77.57] (port=1940 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oNDo0-0002zy-GF; Sun, 14 Aug 2022 09:37:28 -0400 In-Reply-To: <87mtc7fea6.fsf@localhost> (message from Ihor Radchenko on Sun, 14 Aug 2022 15:57:37 +0800) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:239650 Archived-At: > From: Ihor Radchenko > Cc: 57196@debbugs.gnu.org > Date: Sun, 14 Aug 2022 15:57:37 +0800 > > Eli Zaretskii writes: > > > Our "scheduler", such as it is, is in thread.c:really_call_select. It > > basically releases the global lock and lets the first thread waiting > > on the lock to acquire the lock. If someone wants to implement a > > smarter lock-grabbing logic with some kind of "nice" capability, AFAIU > > that's the place to look and modify. > > Do I understand correctly that thread.c:really_call_select simply relies > on pthread itself to select the next thread? What do you mean by "pthread itself"? AFAIU, threads are scheduled by the OS, not by pthreads. So which thread will be the next to grab the lock is up to the OS, the way we programmed it. > Then, a simple pthread_setschedparam inside > systhread.c:sys_thread_create may do the job given that we pass an extra > optional parameter to make-thread. You could try that and see if that helps, although I wouldn't know how you'd select the policy in this case. > 1. There is main thread and the magit/agenda thread > 2. Magit/agenda thread uses a lot of CPU while the main thread is not (I > was typing/navigating the buffer) > 3. Every keypress in the main thread caused thread switch to the > CPU-hungry magit/agenda thread > 4. Frequent switches caused high typing latency because every single key > stroke in the main thread had to wait until the magit/agenda yields. The only way of improving the UX in this case is for the other thread to yield more frequently. > I do not suggest to stop the running thread externally. > > Instead, we may accumulate the thread execution time. Let's call this > "thread 1". > > Then, every time the _other_ running thread yields (stops itself) and > "thread 1" is about to be called, we do the following: > 1. If "thread 1" execution time is less than "duration" thread > property, run the thread. > 2. If "thread 1" execution time is more than "duration", skip running > the thread remembering the time now (pause time). > 3. If "thread 1" execution time is more than "duration" and "pause time" > was more than "break time" thread property ago, set execution time to > 0 and allow the thread to be running. You can do this in your thread function: when it gets to run, check whether it "earned" its time slot, and if not, yield immediately without calling the workhorse code.