From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 14 00:11:31 2022 Received: (at submit) by debbugs.gnu.org; 14 Aug 2022 04:11:31 +0000 Received: from localhost ([127.0.0.1]:35571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oN4yI-0001wc-KC for submit@debbugs.gnu.org; Sun, 14 Aug 2022 00:11:31 -0400 Received: from lists.gnu.org ([209.51.188.17]:57738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oN4yD-0001wS-TM for submit@debbugs.gnu.org; Sun, 14 Aug 2022 00:11:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35044) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oN4yD-0001xh-Ou for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2022 00:11:25 -0400 Received: from mail-pj1-x102e.google.com ([2607:f8b0:4864:20::102e]:41675) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oN4y9-0001ZQ-My for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2022 00:11:25 -0400 Received: by mail-pj1-x102e.google.com with SMTP id t2-20020a17090a4e4200b001f21572f3a4so4208724pjl.0 for ; Sat, 13 Aug 2022 21:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:date:subject:to:from:from:to:cc; bh=xzLtSQKIjtohDfUE0vp4ZJ5HCVWKQz0KJQVoB8wUcWE=; b=BpzKSum2bOwnIhMWQ2Dw+bhorGU2EFs6hUJw9mbBDhg3tpGLn5Ghq+LoQsy+ZGNx7Y +rZKMBT0anj8bL7SHmKdgCfn1iIJcAeFQbB6iby/PbED8lCA8bHwrRPPJxyhm1UZZwQ7 SgGQf4P+uZ3JWoiN+49MRIayVkMTwH+k5KGylVL5tSI3LobWLsiaj4LPifhdHwn+sNvA p6NolKyoogAZ8WxDRsBvldcgWyXRtUysgCXu+I8BkyXXdYV3LYiBEuHPSNPcsd2hNbfn zUo5RxA5StfEqhCxTJw3trNvn67X8Svmf+x5k9hsgdjb/tuDj2ejU6E2MNK6cdP5/l7x uzJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc; bh=xzLtSQKIjtohDfUE0vp4ZJ5HCVWKQz0KJQVoB8wUcWE=; b=m+Fwd6atXPEv0TweHR1y2dbjWZ9jEzCdt2eDi4rwacyTFU3RB9LplnLKtr3qXrnsLI ppzUjklSAPt2Ggg3ZRke3tMsyFWZcQULDBUq8WKTfvnJzkqqd4g5LuPCpl8HHAQjFO2d S5V5BkmIp/HpWofm765wdPsJ4w3PXLUpNv1LNKikw/tdbvsHG/dbfQuatygh3R8tLJkR cCBas/NixNkdpWYnT7EPu/lNf4ho9Ois+ZnR5b7yCCjEyQWQMkEkhqee0CJG8814+KEH KEmNt4A4xSulcZpAKBZ6HH6EEmB71vgdQlhXjqjUXWplTqsWFhnofmsJN1BvKlB8ge2A Ggvg== X-Gm-Message-State: ACgBeo0VxHj1pkTJ9JHMxLpSW7rnTxNwMmus3yr8xnnCTfO89Ad49kv1 Wp9XDrsPmPgRmkTDV0pFUdlrN3wMZiF6rA== X-Google-Smtp-Source: AA6agR67xI3oEVlq0cXy6sEcs55uRpfEeZcjPqUvWUqaHdLo1ehf9LwufhUN6ONG+z9ld0Yel1XcwQ== X-Received: by 2002:a17:90a:9907:b0:1f5:2318:ea6d with SMTP id b7-20020a17090a990700b001f52318ea6dmr12172941pjp.163.1660450279836; Sat, 13 Aug 2022 21:11:19 -0700 (PDT) Received: from localhost ([2409:8a70:2bf:80b0:8ec6:81ff:fe70:339d]) by smtp.gmail.com with ESMTPSA id u20-20020a62d454000000b00534c32592fasm344967pfl.146.2022.08.13.21.11.18 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Aug 2022 21:11:19 -0700 (PDT) From: Ihor Radchenko To: bug-gnu-emacs@gnu.org Subject: 28.1.90; An idea to allow background (low-priority) threads Date: Sun, 14 Aug 2022 12:12:20 +0800 Message-ID: <878rnr1n17.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::102e; envelope-from=yantar92@gmail.com; helo=mail-pj1-x102e.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) Hi, Emacs does have a limited concurrency support via Threads, which is, unfortunately, mostly a toy feature I haven't seen being used a lot. All my attempts to implement some real functionality using threads failed because it is very hard to create real-life threads that do not noticeably block Emacs. Most of the time, Emacs gets quite sluggish, even if the thread yields frequently. Such situation sounds similar to what one may get with 1CPU and multiple processed fighting for the CPU time. This is something that used to be solved with nice command. Could something like nice be implemented for Elisp threads? Or, alternatively, could thread execution be limited in some ways? I have the approach taken by org-element cache processing in mind. org-element limits cache processing using the following variables: (defvar org-element-cache-sync-idle-time 0.6 "Length, in seconds, of idle time before syncing cache.") (defvar org-element-cache-sync-duration 0.04 "Maximum duration, as a time value, for a cache synchronization. If the synchronization is not over after this delay, the process pauses and resumes after `org-element-cache-sync-break' seconds.") (defvar org-element-cache-sync-break 0.3 "Duration, as a time value, of the pause between synchronizations. See `org-element-cache-sync-duration' for more information.") I imagine that something similar could be done for threads. `make-thread' could allow some kind of priority setting that will limit its execution time to comfortable levels, so that the user in main thread can actually interact with Emacs without noticing anything. WDYT? -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92 From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 14 03:03:26 2022 Received: (at 57196) by debbugs.gnu.org; 14 Aug 2022 07:03:26 +0000 Received: from localhost ([127.0.0.1]:35700 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oN7eg-0000Qc-8l for submit@debbugs.gnu.org; Sun, 14 Aug 2022 03:03:26 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36846) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oN7ea-0000QM-Sn for 57196@debbugs.gnu.org; Sun, 14 Aug 2022 03:03:24 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40428) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oN7eV-0006mJ-Jx; Sun, 14 Aug 2022 03:03:15 -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=F2NIhthpWG11wQdbLuOKeeSbhy5U2VDeTAhn3VRLmRk=; b=UpAXPTYNYPcS KCE06Y98yJ2VwauWWf79vzlOCnJAy5n+mUkOSqMCO/leXV7GmUa9fjWUxJuctPZAhTBcEY2WV437l vNMzWoDifvSKY4z10MRQdo8W9lFLq4NEjoJ2rSC7YywpORxvDgjoUfkS/NsFOjGnZ975c2+OW7yjo KalLDj6XTOPFCYXwuDoSrQxqhOyTELoHst99GE9iubctK0Zr0CIIC0BnSqoawSiYCbpD+qJkvcTcF miuOysnddMeOxwrvBWhcqVlbiEwBRHcjAomcdVu2uFH7QZYMXXRQFkkdCASVlYEdk/PqaslNM/EPP pEsWphBat9pJkz3SR1I9dg==; Received: from [87.69.77.57] (port=1530 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 1oN7eV-0006mb-2G; Sun, 14 Aug 2022 03:03:15 -0400 Date: Sun, 14 Aug 2022 10:02:58 +0300 Message-Id: <83bksnl331.fsf@gnu.org> From: Eli Zaretskii To: Ihor Radchenko In-Reply-To: <878rnr1n17.fsf@localhost> (message from Ihor Radchenko on Sun, 14 Aug 2022 12:12:20 +0800) Subject: Re: bug#57196: 28.1.90; An idea to allow background (low-priority) threads References: <878rnr1n17.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57196 Cc: 57196@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Date: Sun, 14 Aug 2022 12:12:20 +0800 > > Emacs does have a limited concurrency support via Threads, which is, > unfortunately, mostly a toy feature I haven't seen being used a lot. > > All my attempts to implement some real functionality using threads > failed because it is very hard to create real-life threads that do not > noticeably block Emacs. Most of the time, Emacs gets quite sluggish, > even if the thread yields frequently. > > Such situation sounds similar to what one may get with 1CPU and > multiple processed fighting for the CPU time. This is something that > used to be solved with nice command. > > Could something like nice be implemented for Elisp threads? 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. TBH, I'm not really sure your analysis, which basically says this is a problem with thread "equality", is correct. Did you try to see what causes the sluggish operation in the cases where you saw it? > I imagine that something similar could be done for threads. > `make-thread' could allow some kind of priority setting that will limit > its execution time to comfortable levels, so that the user in main > thread can actually interact with Emacs without noticing anything. What mechanism will stop the running thread that has exceeded its allotted time? In the current implementation, the thread stops itself when it calls a small set of primitives, but with your proposal we'd need to make the "scheduler" run in a separate thread, which would mean a complete redesign of how threads are scheduled. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 14 03:56:48 2022 Received: (at 57196) by debbugs.gnu.org; 14 Aug 2022 07:56:48 +0000 Received: from localhost ([127.0.0.1]:35742 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oN8UK-0001kL-9M for submit@debbugs.gnu.org; Sun, 14 Aug 2022 03:56:48 -0400 Received: from mail-pj1-f46.google.com ([209.85.216.46]:53829) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oN8UI-0001k8-5c for 57196@debbugs.gnu.org; Sun, 14 Aug 2022 03:56:46 -0400 Received: by mail-pj1-f46.google.com with SMTP id pm17so4540312pjb.3 for <57196@debbugs.gnu.org>; Sun, 14 Aug 2022 00:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc; bh=pqXUYzMzwMoTEms5e6QrAOt0TegO906snoE7/xWtObw=; b=lPWm3Slk1LcK0GAH4LZ1h0vT6+RGF09RjSEN4Fk3V5q8wuznWM0DZ2r1DicLNVBzdA HLebLF932akEJZ+S28aj7UeLR5Dsvd0qP8JZDNMZK2Wx3IHz5IIOx/cxXTVVUQsc1rY+ DHC5q5cHIr7ZKEG7+/YNZha7lmjnwObCMxbDsH9GaHveWbX9G0G7mVkWs4cysgKHq//U QR+1UFKIbQCwY00bWt53Vo10VmZJLD5Ok3KnxPWt4Nhbc//pwnzfP7qrMfkfZ56ymS3C jEEAMSZaV2ZjGAelhxIXR/8iXyKYG0MCzX395qFLUOJ9JoHPH0XMpoefXsA2LWEMekzb bqUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc; bh=pqXUYzMzwMoTEms5e6QrAOt0TegO906snoE7/xWtObw=; b=dBv4bTJgzSQ/RpJ5QwCf3TWCSc2JK7MxfdxOJRVWTBzKgeCE02KmuYtRZzHyCqPzB6 w/SxLQDA7ho9uVDtgHRDN9k/On+MpkO9/HeaNnaL6bozEBfdUMP2LAylgECV8emSAVM/ orZ4YlHwihHWDg2iS7cPeBvOYgUXbNnIBF90Dzj+6Fsm+2Us+nzEh9NaDYclj79ZzOVr 8twOWqDjd5AbQQvApo+/pd7/3uOUd+diEx2i8F8Z3AP2r4SsxPu3MB68VbNDuAbgzIqY xJxvTbvQuaIsfkiWS4j7ZlCL8XhxfG0Kq5cTmophZd2o4kr2W1CbqMin7f2Lxot16FTD eQhA== X-Gm-Message-State: ACgBeo0nx+INKEsJlyiEcNyZ2TjnTxxwFl859u+hmFvcogucFzlhQKL/ oveUXkiksfYlb/SgMD4NWrY= X-Google-Smtp-Source: AA6agR4D/gFMUB7JDHKgQDO++bs5HUrDxMxOg7FFfMSv67xbXUrsEIaX6JOlwhvcL80Z5gXD5m9HuQ== X-Received: by 2002:a17:902:e353:b0:16d:c10a:651a with SMTP id p19-20020a170902e35300b0016dc10a651amr11754786plc.146.1660463796062; Sun, 14 Aug 2022 00:56:36 -0700 (PDT) Received: from localhost ([2409:8a70:2bf:80b0:8ec6:81ff:fe70:339d]) by smtp.gmail.com with ESMTPSA id x124-20020a626382000000b0053291ddd8e5sm3050273pfb.40.2022.08.14.00.56.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Aug 2022 00:56:35 -0700 (PDT) From: Ihor Radchenko To: Eli Zaretskii Subject: Re: bug#57196: 28.1.90; An idea to allow background (low-priority) threads In-Reply-To: <83bksnl331.fsf@gnu.org> References: <878rnr1n17.fsf@localhost> <83bksnl331.fsf@gnu.org> Date: Sun, 14 Aug 2022 15:57:37 +0800 Message-ID: <87mtc7fea6.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 57196 Cc: 57196@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) 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? 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. > TBH, I'm not really sure your analysis, which basically says this is a > problem with thread "equality", is correct. Did you try to see what > causes the sluggish operation in the cases where you saw it? I once tried to write some code for async magit status buffer and for async agenda generation. I am not sure how I can properly determine the cause of sluggish operation, but AFAIU the cause was the following: 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. >> I imagine that something similar could be done for threads. >> `make-thread' could allow some kind of priority setting that will limit >> its execution time to comfortable levels, so that the user in main >> thread can actually interact with Emacs without noticing anything. > > What mechanism will stop the running thread that has exceeded its > allotted time? In the current implementation, the thread stops itself > when it calls a small set of primitives, but with your proposal we'd > need to make the "scheduler" run in a separate thread, which would > mean a complete redesign of how threads are scheduled. 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. "idle-time" may also be used, pausing thread until that much idle-time passed. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92 From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 14 09:37:36 2022 Received: (at 57196) by debbugs.gnu.org; 14 Aug 2022 13:37:36 +0000 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 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 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==; 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 Date: Sun, 14 Aug 2022 16:37:12 +0300 Message-Id: <83tu6fj69j.fsf@gnu.org> From: Eli Zaretskii To: Ihor Radchenko In-Reply-To: <87mtc7fea6.fsf@localhost> (message from Ihor Radchenko on Sun, 14 Aug 2022 15:57:37 +0800) Subject: Re: bug#57196: 28.1.90; An idea to allow background (low-priority) threads References: <878rnr1n17.fsf@localhost> <83bksnl331.fsf@gnu.org> <87mtc7fea6.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57196 Cc: 57196@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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.