From unknown Thu Jun 19 14:06:05 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#64819 <64819@debbugs.gnu.org> To: bug#64819 <64819@debbugs.gnu.org> Subject: Status: 30.0.50; condition-wait not interruptible Reply-To: bug#64819 <64819@debbugs.gnu.org> Date: Thu, 19 Jun 2025 21:06:05 +0000 retitle 64819 30.0.50; condition-wait not interruptible reassign 64819 emacs submitter 64819 Helmut Eller severity 64819 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 24 02:32:29 2023 Received: (at submit) by debbugs.gnu.org; 24 Jul 2023 06:32:29 +0000 Received: from localhost ([127.0.0.1]:41557 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNp7M-0005U5-Rw for submit@debbugs.gnu.org; Mon, 24 Jul 2023 02:32:29 -0400 Received: from lists.gnu.org ([2001:470:142::17]:45878) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNp7J-0005Tq-Em for submit@debbugs.gnu.org; Mon, 24 Jul 2023 02:32:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qNp7C-0007dg-HQ for bug-gnu-emacs@gnu.org; Mon, 24 Jul 2023 02:32:18 -0400 Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qNp7A-0004Xp-Sv for bug-gnu-emacs@gnu.org; Mon, 24 Jul 2023 02:32:18 -0400 Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-3fd2f298712so8081875e9.2 for ; Sun, 23 Jul 2023 23:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690180333; x=1690785133; h=mime-version:message-id:date:subject:to:from:from:to:cc:subject :date:message-id:reply-to; bh=Zf2+Qj0l5qbD3/G9rxL4KQOQS2g+fI7v+ofsdgeTQVc=; b=N+j9S7uFgM/Gz1nfQxou13e9YD4G5ZKQF5BuHAzaGQAIt6USWHOxHWAXbpLrgU4mk+ en0szK4yFGYFakOrYTWZWHiucDksQQ/lU7l/EzkiQaZhts851XraOuU4dD0vx1tEewQg NDPHcv6u79k3zUbRPiIbqAbQaggXL7YfB1GKa64Uz3puFab++JRMZip4jjBi72J9ZTp/ 0mDXFCpbuZz/PEiBBLsFDyFjjOT9VQU/hadVxNvIspN1sBTrnLYczGRyZQFt2z4P2Zdl jmvOAppEGBjnNb1qaSXja7hHZMnxUcjDob/BRHSROVEFwl5ETmUGaTx3ZQu7VMX2mS82 7j4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690180333; x=1690785133; h=mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Zf2+Qj0l5qbD3/G9rxL4KQOQS2g+fI7v+ofsdgeTQVc=; b=H/QPrNB/RE7kBRJ4a0uWbMdDBFH+RGoTU7OqEa1HtbELGk4d8GtdkES0qUsR8M9tgV DNEi9miEuVMPFHCbtuxBSWxiK+WStGlKCzg7wzt7W7+M8keTPTXY4CJj6fMb9s+vMIpo mRjkhzdyWbeZaV+nvik6kMgPbfy2GYTcPIwgxUrxXllT9zw9bG8W8qc0m6fQY73CarBz GLQ5Y1vbtbdVRsuS93vGe4L5l9ot17/hoZWwz3TgPW02brc/KfCT6AE5ErS7utcXc9/V tqQS140L9TXRll9Pk5H2hS9lpvduBRcSSh0tAqtXKaxDNSuuzZBYOunaIicDLsUeTg7U h44g== X-Gm-Message-State: ABy/qLYKyo8st7q5R0pDhTWm8sKVknnmWT1+E6P9Us84LQlSxDMRnQSw I301TEkoys78VAYNtJYaDtcOSVK9AxE= X-Google-Smtp-Source: APBJJlGhXpsRQadhu1TCuZxgq0Y+zKlvnj47t7RbEh9kGx0tDHycfGVlcN+hU9a+dLcHKkSPofMqYA== X-Received: by 2002:adf:e7ca:0:b0:314:1494:fe28 with SMTP id e10-20020adfe7ca000000b003141494fe28mr5066838wrn.53.1690180333328; Sun, 23 Jul 2023 23:32:13 -0700 (PDT) Received: from caladan ([212.46.176.29]) by smtp.gmail.com with ESMTPSA id a23-20020a5d4577000000b00314315071bbsm11737103wrc.38.2023.07.23.23.32.12 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Jul 2023 23:32:12 -0700 (PDT) From: Helmut Eller To: bug-gnu-emacs@gnu.org Subject: 30.0.50; condition-wait not interruptible Date: Mon, 24 Jul 2023 08:32:04 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=2a00:1450:4864:20::336; envelope-from=eller.helmut@gmail.com; helo=mail-wm1-x336.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_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: 1.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: -0.0 (/) --=-=-= Content-Type: text/plain When Emacs is blocked in condition-wait, then C-g doesn't seem to work. E.g. Emacs hangs and pressing C-g has no apparent effect when executing the attached file with: emacs -Q -l deadlock.el -f deadlock Mabye sys_cond_wait could call pthread_cond_timedwait with a fairly long timeout, say one second, and repeatedly check if C-g was pressed. --=-=-= Content-Type: application/emacs-lisp Content-Disposition: inline; filename=deadlock.el Content-Transfer-Encoding: quoted-printable (defun deadlock () (interactive) (let* ((mutex (make-mutex)) (cvar (make-condition-variable mutex))) (with-mutex mutex (condition-wait cvar)))) --=-=-= Content-Type: text/plain Configured using: 'configure --with-xpm=ifavailable --with-jpeg=ifavailable --with-gif=ifavailable --with-tiff=ifavailable' Configured features: CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 GTK3 ZLIB Important settings: value of $LANG: C.UTF-8 locale-coding-system: utf-8-unix --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 24 08:10:07 2023 Received: (at 64819) by debbugs.gnu.org; 24 Jul 2023 12:10:07 +0000 Received: from localhost ([127.0.0.1]:42016 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNuO7-0000Wh-70 for submit@debbugs.gnu.org; Mon, 24 Jul 2023 08:10:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49010) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNuO1-0000W4-C3 for 64819@debbugs.gnu.org; Mon, 24 Jul 2023 08:10:05 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qNuNr-0003jk-CE; Mon, 24 Jul 2023 08:09:54 -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=zSvY60e70kloIXG4QRrtNzsTHCCwXLdLAejP1S2FlEY=; b=nRld0+BDtgK+ ujhcxNvPM/pYM8G/DynwwrTWqnNh0jH92lDl4P5vrACOsVF/M/yjTMAZRsEpzHHbh4XTgAUJ3Hl2v jJLi7FMPsZOBsChY9NERTTnOc3xWKqLfyhpxEpm5eVBUmi9WsFxuQr2MohefhkeVdL0Yx+RjpuG54 azKMkxoYB98zulil6+VgXgGJDAKERDZpWeBeTwYRbXn+YKCJh0bMGaoJXkPv/emgbbFYQCwOJmAp6 Os7vanF0y1FENeEM/J4pO6IDb0u7G8tJkPAOLBjY8aeRKuv1S0KinemdYWqmBFZh9Vqh2vTjjlrEh Zh7E91CygQpY+7tiKIG8Fg==; Received: from [87.69.77.57] (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 1qNuNh-0004GT-AH; Mon, 24 Jul 2023 08:09:43 -0400 Date: Mon, 24 Jul 2023 15:10:24 +0300 Message-Id: <83pm4hse6n.fsf@gnu.org> From: Eli Zaretskii To: Helmut Eller In-Reply-To: (message from Helmut Eller on Mon, 24 Jul 2023 08:32:04 +0200) Subject: Re: bug#64819: 30.0.50; condition-wait not interruptible References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64819 Cc: 64819@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: Helmut Eller > Date: Mon, 24 Jul 2023 08:32:04 +0200 > > When Emacs is blocked in condition-wait, then C-g doesn't seem to work. > E.g. Emacs hangs and pressing C-g has no apparent effect when executing > the attached file with: > > emacs -Q -l deadlock.el -f deadlock > > Mabye sys_cond_wait could call pthread_cond_timedwait with a fairly long > timeout, say one second, and repeatedly check if C-g was pressed. How will we know what to do with C-g if some thread runs Lisp, while one or more other threads are stuck in condition-wait? wouldn't you expect in this case to have C-g go to the running thread? From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 24 08:58:47 2023 Received: (at 64819) by debbugs.gnu.org; 24 Jul 2023 12:58:47 +0000 Received: from localhost ([127.0.0.1]:42101 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNv9D-0006wl-Jm for submit@debbugs.gnu.org; Mon, 24 Jul 2023 08:58:47 -0400 Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]:45172) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNv9B-0006wW-7n for 64819@debbugs.gnu.org; Mon, 24 Jul 2023 08:58:45 -0400 Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-3141fa31c2bso3117034f8f.2 for <64819@debbugs.gnu.org>; Mon, 24 Jul 2023 05:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690203519; x=1690808319; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=qsruRT2HB3bJXgF75zGSRmdzFoWqET3Mcla0ouJAPVE=; b=kPVTYBTR6+FT4OAeg6jU6CqnngWc7b6SbIXBDouNinCpOrhp44sRHoIKSA+lsWSbKg tAUQOTlMBmPcaxRPaiIK5epvrvt0rPXomg/yqS1Ak+lW+/ZdB1w5hX1PvM2xzn74x3Jo Yjn59XZgEPAlyZZFPSsYG4QuNxSD8wytkf2XMQUHBqoICGx8+1xD+uzbB3YmzUF4bypr Q1lJP4O9oIRjWs+QImmk8UAMImcBUWzt4SJ0lRL27RSH4J9q9vxG+OY/8Cq8EKEzBzhO rssOzQyhkMF2H627RhpohrPsz/tcODHBCz58216BCDWi2792tjuUgJJJZW4z54In+6kO Oi7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690203519; x=1690808319; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=qsruRT2HB3bJXgF75zGSRmdzFoWqET3Mcla0ouJAPVE=; b=dNQsyLb0/vVjve+rXJJP8/ml8GUU3gh1t72OSQcDVvd2NGoFQGC2MWWItiGR2z7Sw+ XxYZ1e3LLnzNrs1SG4dCnartSW8W35QGjdbde/cxLjVlzXc2zZuU5cTVSopJiSRFtG9y jvMfDt6XFL3yfBLnLQY92Ht6560LQRI2lJBDma6r8zXirAehKOvFYjAPQAUCDXxnFXNV koeViwW+QY986oVV2wNUYdRbcwiSF7SvDAXeNbmK8JONY9wnMCgKK90B7X6itdlfnKIL OkGbAmgl5uGTAj7Eev3nCZ1U4CF7DoMyEhQaLg9rL/0IhHvk8zEBYTitrOoUg+sEz4Qj bt1Q== X-Gm-Message-State: ABy/qLZYD1Gynwpd0kE83hKJdoC/EwO32Ml8zH0fZzrCWbLe1Cc/bq8f VHBNnfHNenBjyh581Q39CTfQ0lpi8b0= X-Google-Smtp-Source: APBJJlHT4jDXeiziuVO9P3o1lX6eKBsZ/47nWB9PWM8/DMvb5hKN/CmTriHO6JSCjcuqtF+rxlbtJw== X-Received: by 2002:a5d:45c1:0:b0:314:49d2:aaab with SMTP id b1-20020a5d45c1000000b0031449d2aaabmr7265509wrs.8.1690203518791; Mon, 24 Jul 2023 05:58:38 -0700 (PDT) Received: from caladan ([212.46.176.29]) by smtp.gmail.com with ESMTPSA id s14-20020adfea8e000000b003143be36d99sm12905999wrm.58.2023.07.24.05.58.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Jul 2023 05:58:38 -0700 (PDT) From: Helmut Eller To: Eli Zaretskii Subject: Re: bug#64819: 30.0.50; condition-wait not interruptible In-Reply-To: <83pm4hse6n.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 24 Jul 2023 15:10:24 +0300") References: <83pm4hse6n.fsf@gnu.org> Date: Mon, 24 Jul 2023 14:58:37 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 64819 Cc: 64819@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: -1.0 (-) On Mon, Jul 24 2023, Eli Zaretskii wrote: > How will we know what to do with C-g if some thread runs Lisp, while > one or more other threads are stuck in condition-wait? wouldn't you > expect in this case to have C-g go to the running thread? We could say that C-g sets quit-flag and causes all blocking calls to condition-wait to return nil (spurious wakeup). At that point all threads are conceptually running. Then the first thread (unspecified which one) who calls maybe_quit() finishes handling C-g and clears quit-flag afterwards. Those threads who don't feel prepared to handle C-g can bind inhibit-quit. Helmut From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 24 09:33:47 2023 Received: (at 64819) by debbugs.gnu.org; 24 Jul 2023 13:33:47 +0000 Received: from localhost ([127.0.0.1]:42185 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNvh4-0007qV-LM for submit@debbugs.gnu.org; Mon, 24 Jul 2023 09:33:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35014) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNvh2-0007qJ-Rs for 64819@debbugs.gnu.org; Mon, 24 Jul 2023 09:33:45 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qNvgw-0000eO-2U; Mon, 24 Jul 2023 09:33:38 -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=FDm79kcPVPTh63xNt4//AF92/C5S2SOeyaZCjRjCXDU=; b=MS2MHyDrO+Fi i7nt+BRqhvpV4xvNteL5fkBA2zCCXthYJfe50k190fNo1rvcSDlTM9gNitvss5fPjVClbmbkmAkhA fHmLuSDmjW0yYW8EMzPRs6wzOju7LJFzC660Wqkd1rgOStXh+abXw3ygUKGw7wu6sO6YykZ1Dyqqt c9oolhMbrDdOKyiX44sPtYqwJDL4jfSL8ao4NztudcBpz1QgAurJ0ZN+vpHewU0kt/9vdauW7wmIA tSsGGlbVmUAowhn9/MLXGuKaK/+OeAIV8QHWsg/rqMN9p2jMKq3O4teny2zPVwlKt6nqgEJAtKR5o jIPqpnVh0czlERHW5+yH9g==; Received: from [87.69.77.57] (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 1qNvgr-0003xb-V1; Mon, 24 Jul 2023 09:33:37 -0400 Date: Mon, 24 Jul 2023 16:34:17 +0300 Message-Id: <838rb5saau.fsf@gnu.org> From: Eli Zaretskii To: Helmut Eller In-Reply-To: (message from Helmut Eller on Mon, 24 Jul 2023 14:58:37 +0200) Subject: Re: bug#64819: 30.0.50; condition-wait not interruptible References: <83pm4hse6n.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64819 Cc: 64819@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: Helmut Eller > Cc: 64819@debbugs.gnu.org > Date: Mon, 24 Jul 2023 14:58:37 +0200 > > On Mon, Jul 24 2023, Eli Zaretskii wrote: > > > How will we know what to do with C-g if some thread runs Lisp, while > > one or more other threads are stuck in condition-wait? wouldn't you > > expect in this case to have C-g go to the running thread? > > We could say that C-g sets quit-flag and causes all blocking calls to > condition-wait to return nil (spurious wakeup). At that point all > threads are conceptually running. Then the first thread (unspecified > which one) who calls maybe_quit() finishes handling C-g and clears > quit-flag afterwards. Those threads who don't feel prepared to handle > C-g can bind inhibit-quit. I don't think we can allow more than one thread at a time to run the parts of the Lisp interpreter that lead to maybe_quit. Also, I don't think what you describe, even if it were possible, is what users expect: they expect that the thread which is running is interrupted, and either exits or handles the quit, and all the other threads still wait for the condition var. So I think to do anything smarter in the deadlock situation you describe we'd need to detect the deadlock first. Once we do that (which isn't easy: perhaps do that in the signal handler?), we'd need to decide which of the deadlocked threads to free, which is also not trivial. Hmmm... Btw, did you try your recipe in a Unix TTY? There, C-g actually delivers SIGINT to Emacs, so you might see a different behavior (or a crash ;-). From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 24 10:57:16 2023 Received: (at 64819) by debbugs.gnu.org; 24 Jul 2023 14:57:17 +0000 Received: from localhost ([127.0.0.1]:43774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNwzs-00025l-GR for submit@debbugs.gnu.org; Mon, 24 Jul 2023 10:57:16 -0400 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]:55780) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNwzp-00025U-En for 64819@debbugs.gnu.org; Mon, 24 Jul 2023 10:57:14 -0400 Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-4fddd4e942eso6265432e87.3 for <64819@debbugs.gnu.org>; Mon, 24 Jul 2023 07:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690210627; x=1690815427; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=ts8r9MKNvcAm2L8n0yT2T3Vwr2RoBW1152sGRqSwWCM=; b=Rf/0O6AJeu2ZhWS//T3Ibykljqr7/j7NB5aWeuAfkd4qyuULJDDh/MPgm6ROQTU5RK BtvxBoyzP2Kul1a/5MGjhP361gtSbTa4Tb7S+J8aqXzTlZSuF1vonYnoGDKZHpTo0JO1 wvffzNxJi+ibX+sb9MzABnNxIG4fBVCii21RquAvsrOT5GYtOKMQrn1sTOxcXUkHRQhg WS+4SGB3Y33wJe6HFg3ZqtZbkfd0MiAZ8KPyYtB26Cwkn6e9To3E3HZHC2rGrd9Ty/wH SwHyEdn/ONix1s5/Zt8Afq7TpBQ7sMi4OG4ElrhNhEC7xHjASa6Hm9Iyqd2F+HTKdJ9T 0lSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690210627; x=1690815427; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ts8r9MKNvcAm2L8n0yT2T3Vwr2RoBW1152sGRqSwWCM=; b=gVSFTS3XeAAml+cqM2CD39z7/cCdQq+Nza7cvwqMauSxouNVGsoaT+V1gKFmyvb70T Qvf5nFHSLtRq2g3SlebgsgtwwBdfKYyKdyWzTDbEGzfT2gzgQG2xUKur9LIw4XnCv0a+ RJJ40gy9178YI/fhHzPk1T4pbdA4fBMGD4NjDt/6zFr9+dPgPGdteRK9mWsyj+b4oi1M SDVgVVfpN+JlOqyCwtynmIWnbktJgb3jo1oWxEAhnzcCupqzTz0QGco1s9+NLxvwCp1w 3NhX75cYQD6hBKVRzkXA5bmvv8jhF0cq8pXUpmWq68T+92tHC7gX9N3HdUmx1tiHPYIm 4trQ== X-Gm-Message-State: ABy/qLY8IeowfzaQivzmPERAjxh2HGsYvWItiNlWVlXH8Cca62PBbywO TUP9NJlva2GBb6p/z4WCHf3HlG3Ey8k= X-Google-Smtp-Source: APBJJlGt5HYPgDX8POBPiv1MMZ+kQgDmSURUZnnTKtNrYAlIBveYaZrD60Ql5g3sNnbTJdMk6SaKLw== X-Received: by 2002:a05:6512:468:b0:4f8:ff52:93b7 with SMTP id x8-20020a056512046800b004f8ff5293b7mr4568991lfd.30.1690210627027; Mon, 24 Jul 2023 07:57:07 -0700 (PDT) Received: from caladan ([212.46.176.29]) by smtp.gmail.com with ESMTPSA id f14-20020a7bcd0e000000b003fc01f7b415sm13372897wmj.39.2023.07.24.07.57.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Jul 2023 07:57:06 -0700 (PDT) From: Helmut Eller To: Eli Zaretskii Subject: Re: bug#64819: 30.0.50; condition-wait not interruptible In-Reply-To: <838rb5saau.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 24 Jul 2023 16:34:17 +0300") References: <83pm4hse6n.fsf@gnu.org> <838rb5saau.fsf@gnu.org> Date: Mon, 24 Jul 2023 16:57:05 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 64819 Cc: 64819@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: -1.0 (-) On Mon, Jul 24 2023, Eli Zaretskii wrote: >> From: Helmut Eller >> We could say that C-g sets quit-flag and causes all blocking calls to >> condition-wait to return nil (spurious wakeup). At that point all >> threads are conceptually running. Then the first thread (unspecified >> which one) who calls maybe_quit() finishes handling C-g and clears >> quit-flag afterwards. Those threads who don't feel prepared to handle >> C-g can bind inhibit-quit. > > I don't think we can allow more than one thread at a time to run the > parts of the Lisp interpreter that lead to maybe_quit. I didn't suggest that. Nor did I suggest that the thread scheduler should switch away from the currently running thread. What I did suggest is that the thread blocked in condition-wait is considered runnable. So that the thread scheduler is allowed to pick this thread the next time when somebody calls thread-yield or condition-wait. To the thread it will look like a spurious wakeup (i.e. condition-wait returned but the condition isn't actually true) but Lisp code must already be prepared for such a situation. The bytecode interpreter calls maybe_quit before every call or backward branch, so maybe_quit will be called very soon after the spurious wakeup. > Also, I don't think what you describe, even if it were possible, is > what users expect: they expect that the thread which is running is > interrupted, and either exits or handles the quit, and all the other > threads still wait for the condition var. Maybe we can agree on this: when only one thread exists and it is blocked in condition-wait, then condition-wait should be interruptible by C-g. For the situation where some threads are blocked in condition-wait and one other thread is running, I think that running thread would call maybe_quit and clear quite-flag before calling thread-yield. The other threads would observe spurious wakeups as soon as they are allowed to run. > So I think to do anything smarter in the deadlock situation you > describe we'd need to detect the deadlock first. Once we do that > (which isn't easy: perhaps do that in the signal handler?), we'd need > to decide which of the deadlocked threads to free, which is also not > trivial. Hmmm... I doubt that deadlock detection is possible in the general case. E.g. how could we possibly know that a timer is or isn't going to call condition-notify in 5 seconds? > Btw, did you try your recipe in a Unix TTY? There, C-g actually > delivers SIGINT to Emacs, so you might see a different behavior (or a > crash ;-). When I run the recipe with: "emacs -nw -l deadlock.el -f deadlock" then I see the emergency escape feature kick in. Only after the second C-g (of course). A single C-g doesn't seem to do anything. Helmut From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 24 12:23:01 2023 Received: (at 64819) by debbugs.gnu.org; 24 Jul 2023 16:23:01 +0000 Received: from localhost ([127.0.0.1]:43855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNyKq-0004bL-Lv for submit@debbugs.gnu.org; Mon, 24 Jul 2023 12:23:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50910) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNyKk-0004b0-Ct for 64819@debbugs.gnu.org; Mon, 24 Jul 2023 12:22:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qNyKe-0008M2-R5; Mon, 24 Jul 2023 12:22:48 -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=sMILZ7n9xkmPnm+ohq9LjtooQxtHCZji/cnV/IIZu20=; b=Ezg3Uv0llUiO mdyU3KUkCyZ12mMYB7RbAP61GmTFMBku3yPCWynsGzBL13c9m4xfZnnYOkK5M1TovxLOIcQSQhbqe 8s8HbO8vGW4VA+StmOt2P2J/FZmolT+dLo/XU4PaYW3ouFgIPf6GuAcYu9uwYdVme3x+++oNulqNX 1aFCMZb4NRnnHqLQqhrjn7/Do/Qx7M8eAtMDKl+Z+f4Zy1zNSyWvq5JA4sQ1FHLIAtPoFbUisy6sv I0EmJXM/H6NXy06W4i+YjCAZvnis92r0G7Y6dD4G0AoAw5r/yLmZ8sZsyaLdaMMb2szaKyF911SYS f+qS3NQidhdiRIlvI0jTtw==; Received: from [87.69.77.57] (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 1qNyKd-0006E9-T1; Mon, 24 Jul 2023 12:22:48 -0400 Date: Mon, 24 Jul 2023 19:23:31 +0300 Message-Id: <83r0oxqnwc.fsf@gnu.org> From: Eli Zaretskii To: Helmut Eller In-Reply-To: (message from Helmut Eller on Mon, 24 Jul 2023 16:57:05 +0200) Subject: Re: bug#64819: 30.0.50; condition-wait not interruptible References: <83pm4hse6n.fsf@gnu.org> <838rb5saau.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64819 Cc: 64819@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: Helmut Eller > Cc: 64819@debbugs.gnu.org > Date: Mon, 24 Jul 2023 16:57:05 +0200 > > On Mon, Jul 24 2023, Eli Zaretskii wrote: > > >> From: Helmut Eller > >> We could say that C-g sets quit-flag and causes all blocking calls to > >> condition-wait to return nil (spurious wakeup). At that point all > >> threads are conceptually running. Then the first thread (unspecified > >> which one) who calls maybe_quit() finishes handling C-g and clears > >> quit-flag afterwards. Those threads who don't feel prepared to handle > >> C-g can bind inhibit-quit. > > > > I don't think we can allow more than one thread at a time to run the > > parts of the Lisp interpreter that lead to maybe_quit. > > I didn't suggest that. Nor did I suggest that the thread scheduler > should switch away from the currently running thread. You did say "At that point all threads are conceptually running." Perhaps I misunderstood what you meant. > What I did suggest is that the thread blocked in condition-wait is > considered runnable. So that the thread scheduler is allowed to pick > this thread the next time when somebody calls thread-yield or > condition-wait. We don't have a scheduler. The threads "schedule themselves", in the sense that the first thread that succeeds to grab the global lock gets to run, and the others wait for the lock to be released. So for this to work, the C-g handler will have to release some thread. > Maybe we can agree on this: when only one thread exists and it is > blocked in condition-wait, then condition-wait should be interruptible > by C-g. Yes, this is simpler. > For the situation where some threads are blocked in condition-wait and > one other thread is running, I think that running thread would call > maybe_quit and clear quite-flag before calling thread-yield. The other > threads would observe spurious wakeups as soon as they are allowed to > run. I'm not sure I follow here. First, no one guarantees that a running thread will call thread-yield; it could call sit-for or somesuch instead. And second if C-g only sets quit-flag, then it will not be able to release a stuck thread; and if it does release a stuck thread, it will somehow need to stop the running one, or we will have more than one thread running. > > So I think to do anything smarter in the deadlock situation you > > describe we'd need to detect the deadlock first. Once we do that > > (which isn't easy: perhaps do that in the signal handler?), we'd need > > to decide which of the deadlocked threads to free, which is also not > > trivial. Hmmm... > > I doubt that deadlock detection is possible in the general case. > E.g. how could we possibly know that a timer is or isn't going to call > condition-notify in 5 seconds? We are talking about a situation where the user typed C-g, so we have some indication that the situation is not normal. > > Btw, did you try your recipe in a Unix TTY? There, C-g actually > > delivers SIGINT to Emacs, so you might see a different behavior (or a > > crash ;-). > > When I run the recipe with: "emacs -nw -l deadlock.el -f deadlock" then > I see the emergency escape feature kick in. Only after the second C-g > (of course). A single C-g doesn't seem to do anything. As expected, thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 25 04:06:53 2023 Received: (at 64819) by debbugs.gnu.org; 25 Jul 2023 08:06:53 +0000 Received: from localhost ([127.0.0.1]:44590 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qOD4H-0002MU-4K for submit@debbugs.gnu.org; Tue, 25 Jul 2023 04:06:53 -0400 Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]:53464) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qOD4B-0002MD-TQ for 64819@debbugs.gnu.org; Tue, 25 Jul 2023 04:06:52 -0400 Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-3fbc12181b6so51133165e9.2 for <64819@debbugs.gnu.org>; Tue, 25 Jul 2023 01:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690272402; x=1690877202; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=2+7PaJJdax7RZcquvQuR73pVikEc3BmHffUAdOO2dRA=; b=GwBX2L4VE1957f7g3Vy9Q2x3F+3yPhzKLN+EShOArI8QK2DQYMuCWpGo6l8DkKVcXO ibYmNRteNtDhOpdrf8h//1PtTSZpJHTj8qCdmvkM1UqhgE69rmGeQCP7/ntwwAMZBBzG D504ImK2jMg6peWAQZz/tL5lnTNqOAGgvV9zBPb8SswG//8UCkKzcjzvekMjkJjmo3DF F01yR/es8ty8QzoysIHJQwIJ7GhRIJHpL578bAAPnXxINIThQ2dVaIF4J/+Ks4USf+nx /gJ9yhI8/uCBDA2QVjyhspg5ztf9oGhL+xrmcwW5JDnpN3KL4JsQxlRmV5iA7pDo0yvk tcVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690272402; x=1690877202; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2+7PaJJdax7RZcquvQuR73pVikEc3BmHffUAdOO2dRA=; b=FKnbYvSfEarqH1z40jn9etEy37nBowVY9Oe6FNMyB2ATREXZv7ChAlMxsmQiFjQvdg dytaypkZGKl7B01F7I0L8nfFXgLIL90YvjWkCsyQt5RQLaCoCP/q9i2WyO6nfz1WY8DW uTEDEdeTAaz/txYPHeQA9CzSaDcfWiFMFKfxzrwaTgwazK1FWN9Vt4pGlnJ5qThpQ63d SaLd6go0OSzdgbbCTyaB1w1tidIq1PC3xjtgra3M6fnyWzIZTXBoJsWar046DVb8Nk4R AyCkhvY3ugS3BUT2WDwWJKgsUJ7D/ZObgoh0Xznw0JEPml27kZkZPDPjqGlZFP8PyrYe nFHA== X-Gm-Message-State: ABy/qLYzzpI2DFEZTZv8wcsqnK627JBHOqv5QTk5TxRLHhl4DuswqUjH 6ilTfdS/OzP3wZUSjxTgWyOXfCTMB5g= X-Google-Smtp-Source: APBJJlH/FZlQPx1zWX9iR2y4g6COFMc/JIrc5V9hLwWFXaBuZXkLMs88BYIZvOwMAUFK71YI5wxtFA== X-Received: by 2002:a05:600c:2106:b0:3f9:ba2:5d19 with SMTP id u6-20020a05600c210600b003f90ba25d19mr8733894wml.33.1690272401893; Tue, 25 Jul 2023 01:06:41 -0700 (PDT) Received: from caladan (dial-183072.pool.broadband44.net. [212.46.183.72]) by smtp.gmail.com with ESMTPSA id j16-20020adfea50000000b0031424f4ef1dsm15588381wrn.19.2023.07.25.01.06.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Jul 2023 01:06:41 -0700 (PDT) From: Helmut Eller To: Eli Zaretskii Subject: Re: bug#64819: 30.0.50; condition-wait not interruptible In-Reply-To: <83r0oxqnwc.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 24 Jul 2023 19:23:31 +0300") References: <83pm4hse6n.fsf@gnu.org> <838rb5saau.fsf@gnu.org> <83r0oxqnwc.fsf@gnu.org> Date: Tue, 25 Jul 2023 10:06:40 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 64819 Cc: 64819@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: -1.0 (-) --=-=-= Content-Type: text/plain On Mon, Jul 24 2023, Eli Zaretskii wrote: [...] > So for this to work, the C-g handler will have to release some thread. Here is a patch that works good enough for me: --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Make-condition-wait-interruptible-by-C-g.patch >From 4de3198c10c4efaeaffdf43ba5e5b0f1729a7f09 Mon Sep 17 00:00:00 2001 From: Helmut Eller Date: Tue, 25 Jul 2023 10:03:53 +0200 Subject: [PATCH] Make condition-wait interruptible by C-g Code like (let* ((mutex (make-mutex)) (cvar (make-condition-variable mutex))) (with-mutex mutex (condition-wait cvar))) will block in pthread_cond_wait. The problem is that pthread_cond_wait may or may not return when it gets interrupted by a signal (SIGIO). On Linux it doesn't return and so even if a signal handler sets pending_signals=true nobody processes those pending signals. The patch modifies the signal handler so that it will force a spurious wakeup when the current thread is blocked in condition-wait. * src/keyboard.c (handle_input_available_signal) (handle_interrupt): Call maybe_awake_current_thread. * src/thread.c (maybe_awake_current_thread): New. * src/thread.h (maybe_awake_current_thread): New prototype. --- src/keyboard.c | 8 +++++++- src/thread.c | 16 ++++++++++++++++ src/thread.h | 1 + 3 files changed, 24 insertions(+), 1 deletion(-) diff --git a/src/keyboard.c b/src/keyboard.c index 41cda2e65de..f45bafa96c0 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -7745,6 +7745,10 @@ handle_input_available_signal (int sig) if (input_available_clear_time) *input_available_clear_time = make_timespec (0, 0); + +#ifdef THREADS_ENABLED + maybe_awake_current_thread (); +#endif } static void @@ -11556,8 +11560,10 @@ handle_interrupt (bool in_signal_handler) /* If we were called from a signal handler, we must be in the main thread, see deliver_process_signal. So we must make sure the main thread holds the global lock. */ - if (in_signal_handler) + if (in_signal_handler) { maybe_reacquire_global_lock (); + maybe_awake_current_thread(); + } #endif if (waiting_for_input && !echoing) quit_throw_to_read_char (in_signal_handler); diff --git a/src/thread.c b/src/thread.c index b8ca56fd372..0bd949f5779 100644 --- a/src/thread.c +++ b/src/thread.c @@ -172,6 +172,22 @@ maybe_reacquire_global_lock (void) } } +/* This is called from keyboard.c when it sets pending_signals=true. + If the current thread is waiting, we create a spurious wakeup by + broadcasting on wait_condvar. This is necessary because + pthread_cond_wait may or may not return if it was interrupted by a + signal (SIGIO). Without the wakeup, nobody would process a + potential C-g. +*/ +void +maybe_awake_current_thread (void) +{ + if (current_thread->wait_condvar != NULL) + { + sys_cond_broadcast (current_thread->wait_condvar); + } +} + static void diff --git a/src/thread.h b/src/thread.h index 9b14cc44f35..60f601a6248 100644 --- a/src/thread.h +++ b/src/thread.h @@ -311,6 +311,7 @@ extern void finalize_one_thread (struct thread_state *state); extern void finalize_one_mutex (struct Lisp_Mutex *); extern void finalize_one_condvar (struct Lisp_CondVar *); extern void maybe_reacquire_global_lock (void); +extern void maybe_awake_current_thread (void); extern void init_threads (void); extern void syms_of_threads (void); -- 2.39.2 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 25 08:18:02 2023 Received: (at 64819) by debbugs.gnu.org; 25 Jul 2023 12:18:02 +0000 Received: from localhost ([127.0.0.1]:44814 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qOGzG-0003ZJ-CZ for submit@debbugs.gnu.org; Tue, 25 Jul 2023 08:18:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37302) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qOGzB-0003Z2-BH for 64819@debbugs.gnu.org; Tue, 25 Jul 2023 08:17:57 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qOGz4-0007jS-NJ; Tue, 25 Jul 2023 08:17:47 -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=OqlwZbw2ENpM6kkLKGSJqBDoV/zE73D8czhHRPbgCzg=; b=I8xoOzZbiCsr LNcgR5M6Lp88AU5zRv8j0SYTwme+HVbIB8JGDVUb8eLoTmIfFWmTv1bjrNn60ZGoWc+DdN882JNgH rKcJkYjRrQYqtO6JjslMVNiC6nVYyEhiZpO2xTReAij80Kp7kgGjgDUxtgANZmYX1uAosEZw3o6MY /doCI9eos6x03n+jIOj4xpU+eN4s3roaSVX9e6/HbTpfRV/oCk3dXuq2xRr4eNtW9vzeZVWt+nHKS GwIm35AKtDBhCBpJxx9qrsXXdDZNBUeVI/LEB8a4T+U9BIsBr7Gwodvwl6EO2ssX9trVB3qILvu7A 6flR5e7JHA3h9tVjL6DZyA==; Received: from [87.69.77.57] (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 1qOGz2-00032a-AQ; Tue, 25 Jul 2023 08:17:45 -0400 Date: Tue, 25 Jul 2023 15:18:29 +0300 Message-Id: <83351cqj56.fsf@gnu.org> From: Eli Zaretskii To: Helmut Eller In-Reply-To: (message from Helmut Eller on Tue, 25 Jul 2023 10:06:40 +0200) Subject: Re: bug#64819: 30.0.50; condition-wait not interruptible References: <83pm4hse6n.fsf@gnu.org> <838rb5saau.fsf@gnu.org> <83r0oxqnwc.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64819 Cc: 64819@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: Helmut Eller > Cc: 64819@debbugs.gnu.org > Date: Tue, 25 Jul 2023 10:06:40 +0200 > > On Mon, Jul 24 2023, Eli Zaretskii wrote: > > [...] > > So for this to work, the C-g handler will have to release some thread. > > Here is a patch that works good enough for me: Thanks. If you are currently working on or using some packages that use Lisp threads, please run with this patch for a while and come back in a couple of weeks if you see no problems with it; then we can install this on master. (It will need a small addition for MS-Windows, but that can be handled later.) A test for this, if possible, would also be appreciated, even if it can only be run manually (we have the test/manual/ directory for those). If you do not intend to use threads any time soon, I guess we can install this on master and let someone else be the guinea pig... A couple of minor stylistic comments: > - if (in_signal_handler) > + if (in_signal_handler) { > maybe_reacquire_global_lock (); > + maybe_awake_current_thread(); > + } Please use the GNU style of braces: if (something) { do_1; do_2; } > +void > +maybe_awake_current_thread (void) > +{ > + if (current_thread->wait_condvar != NULL) > + { > + sys_cond_broadcast (current_thread->wait_condvar); > + } We don't use braces when the body of 'if' has just one statement. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 25 08:59:46 2023 Received: (at 64819) by debbugs.gnu.org; 25 Jul 2023 12:59:46 +0000 Received: from localhost ([127.0.0.1]:44867 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qOHdi-0004f8-IP for submit@debbugs.gnu.org; Tue, 25 Jul 2023 08:59:46 -0400 Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:42139) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qOHdh-0004ev-KE for 64819@debbugs.gnu.org; Tue, 25 Jul 2023 08:59:46 -0400 Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-3fb4146e8fcso35789225e9.0 for <64819@debbugs.gnu.org>; Tue, 25 Jul 2023 05:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690289980; x=1690894780; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=CD46dOR710927dCIHOG143d0ssgJMl9wFEU6i9WhUHQ=; b=U7M3LIxdUrtKtGrsus7JKQgcRI+F9nfKDdj3DoWGdBe6Z+QaD5A2P3uBxvYvNLvsDa ipOTNJOBXVGKbV41izidQI442E+63KKfs/T8f2D2vDJBC8la3/Qj7MoRKaTYKt13U5Pj fouw1fzCposgZ6Qh6mDG9vA0WM0NTBZHT8Ac6/bbG1aeGaLDbU+zKlXNFwbR+oxRxJmK F2uiaYgoCAOSSHMTavUAgVfcsM5S4Mw2H3B8/VEi/WxFFK7YSXDH+sTGJ5IP3xJEntPe ErIxVVn8M+/X6yS3B5q/2NP6Q61mW2k9c95bTPiESbVraKOcO9Ib8HCAtoW7S443StwM 0mNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690289980; x=1690894780; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=CD46dOR710927dCIHOG143d0ssgJMl9wFEU6i9WhUHQ=; b=TU4g/w+KhAvfTxb3p5xvVe3ScYBQ61Ra6Vey6Oy6fnhykh0SOqVKAKT3CYJLi2g0M3 Hn52FhulUUsaHd3FgQjsI82x+OG3vk3rxKpEWpO2XB678hNAtu7GcjJe6hiq2HEU6EEq 0T/NKMIyMnO0MXlyua8AE1P2S8poX4t0OCO/Zbb0s+D6dwV3ZAYVMLhwpPL1/aceyW8P 0JxnpkLR62asqhJZFpaBpyt0QRORO2dg1Kh0vPSvHIlBN7ppfYbtxjEmQBmMMRgQe0vz 6vaE2yTRkYPuTxCbzXuJxbsa/VuaQglFY3jO3gNvOu8bNS7a4QEOw8to+cH4S2WXK1gK CPpQ== X-Gm-Message-State: ABy/qLZ357+VhbQZEXeofLl9MRZzkqsd/iY5PmMTFjypXxHNFbjAsLxE Ji7rj4lYEddOwvgpHzfMV05f+fFsll0= X-Google-Smtp-Source: APBJJlEKdmlPdOtdpI5ZUnLL3Dx3EF4diuOaKPV62XrzgGZnGVz984fn4ne9N5rLJ3PwOgvk0cn47g== X-Received: by 2002:a05:600c:1d1f:b0:3f9:68f:9c1a with SMTP id l31-20020a05600c1d1f00b003f9068f9c1amr1937563wms.15.1690289979573; Tue, 25 Jul 2023 05:59:39 -0700 (PDT) Received: from caladan (dial-183072.pool.broadband44.net. [212.46.183.72]) by smtp.gmail.com with ESMTPSA id q21-20020a1ce915000000b003fba6709c68sm13253357wmc.47.2023.07.25.05.59.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Jul 2023 05:59:38 -0700 (PDT) From: Helmut Eller To: Eli Zaretskii Subject: Re: bug#64819: 30.0.50; condition-wait not interruptible In-Reply-To: <83351cqj56.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 25 Jul 2023 15:18:29 +0300") References: <83pm4hse6n.fsf@gnu.org> <838rb5saau.fsf@gnu.org> <83r0oxqnwc.fsf@gnu.org> <83351cqj56.fsf@gnu.org> Date: Tue, 25 Jul 2023 14:59:38 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 64819 Cc: 64819@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: -1.0 (-) On Tue, Jul 25 2023, Eli Zaretskii wrote: > Thanks. If you are currently working on or using some packages that > use Lisp threads, please run with this patch for a while and come back > in a couple of weeks if you see no problems with it; then we can > install this on master. (It will need a small addition for > MS-Windows, but that can be handled later.) A test for this, if > possible, would also be appreciated, even if it can only be run > manually (we have the test/manual/ directory for those). I will try to write a simple multi-threaded HTTP client or proxy to exercise the threading primitives a bit. > If you do not intend to use threads any time soon, I guess we can > install this on master and let someone else be the guinea pig... The patch doesn't handle the situation where current_thread==NULL. Not sure how that can happen, but the patch is definitely not ready for master. Helmut From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 02 17:58:47 2023 Received: (at 64819) by debbugs.gnu.org; 2 Sep 2023 21:58:47 +0000 Received: from localhost ([127.0.0.1]:38825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcYdj-0003bU-5w for submit@debbugs.gnu.org; Sat, 02 Sep 2023 17:58:47 -0400 Received: from mail-lf1-x129.google.com ([2a00:1450:4864:20::129]:54780) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcYdg-0003bG-LR for 64819@debbugs.gnu.org; Sat, 02 Sep 2023 17:58:45 -0400 Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-50078e52537so485931e87.1 for <64819@debbugs.gnu.org>; Sat, 02 Sep 2023 14:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693691908; x=1694296708; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=kneUwDRvKsQ2yB6ESPrIdVq47bd7digTFEQX5RQUiDM=; b=YaRw3StKcq/PlDDqYbbIxB2zp52U4GGJrxnAjjUWFS45pt6hTsJMika8rLcg3sefjQ mVbFrJ80JSCw3mtS7IUljaz4Re//cyRDs+uRXI75iTWCFhtDYNRpZgHOtZUyTR1ikksS UgA7W9TyVE/Wrp+vhV4qgPIyrkHWD3yV0ZjhaIRvzUvQObAEgwlYcalEAgek4bvtOwz/ NCTjn6wnwKDB0olBPElOCG3u9/kJMl7iOBqLDwIVLH32c8nGm3q+UFjF67jNNc6BzT/E Kwkl0Koj+L0/8NQNzToouPMWlxt0hn7OHDVtd4Y+Gyexb6C8aBZJzqdSAJ/84xbkfgDO O+RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693691908; x=1694296708; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kneUwDRvKsQ2yB6ESPrIdVq47bd7digTFEQX5RQUiDM=; b=TQQnFnRiAyygd/01V+7HMYhLB1Mzp6QwQxt7Cr8beHQi56uVq5hmSjdSXhfkOA2T7M x8iNAP9KwHn5MkYv09Ekq6Wy5uE53iTtYonhGhCjH8SSTB7InXol6ZwamzZSksZepLLO 7G6sxe3fRPTsnA9ANgElz3wzSUmWzrVeLJ19UtpfwwZduuLi85gNRs1aMUCxYSP8EDeQ AoNKbG65t2S+9hDQQ0oEqEQJmY6G/LQjzo7QvN8rnQboJehkLqtirA0/gYeTIpIdO5PP D245EiLF6cbM6O2hmzL5Gloe6k3Fyp1oivy/Jqzh54r3tcsZ6ZgOn90oIIl0BbrCOfJA 8Yug== X-Gm-Message-State: AOJu0Yz2/aKZBoW+VpVbUkQY5WBbmoqKHHrdt/eG/izCoA9ccQcG1wHb CNLDEjofJu39O1aO0SUSecBG7/xfXhuKopPfFHQ= X-Google-Smtp-Source: AGHT+IFr9/wMsfCZ/YD4vb6iNq4IvVRwqi/eELTVulrANucYa3haxJRq3ogpZASox9TfM9Lqop233pWGLAybVZtGpNE= X-Received: by 2002:ac2:48a1:0:b0:4ff:8f12:c4d7 with SMTP id u1-20020ac248a1000000b004ff8f12c4d7mr3462531lfg.31.1693691908385; Sat, 02 Sep 2023 14:58:28 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 2 Sep 2023 14:58:27 -0700 From: Stefan Kangas In-Reply-To: References: <83pm4hse6n.fsf@gnu.org> <838rb5saau.fsf@gnu.org> <83r0oxqnwc.fsf@gnu.org> <83351cqj56.fsf@gnu.org> MIME-Version: 1.0 Date: Sat, 2 Sep 2023 14:58:27 -0700 Message-ID: Subject: Re: bug#64819: 30.0.50; condition-wait not interruptible To: Helmut Eller , Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64819 Cc: 64819@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: -1.0 (-) Helmut Eller writes: > On Tue, Jul 25 2023, Eli Zaretskii wrote: > >> Thanks. If you are currently working on or using some packages that >> use Lisp threads, please run with this patch for a while and come back >> in a couple of weeks if you see no problems with it; then we can >> install this on master. (It will need a small addition for >> MS-Windows, but that can be handled later.) A test for this, if >> possible, would also be appreciated, even if it can only be run >> manually (we have the test/manual/ directory for those). > > I will try to write a simple multi-threaded HTTP client or proxy to > exercise the threading primitives a bit. > >> If you do not intend to use threads any time soon, I guess we can >> install this on master and let someone else be the guinea pig... > > The patch doesn't handle the situation where current_thread==NULL. Not > sure how that can happen, but the patch is definitely not ready for > master. Did you get any further with this? From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 03 15:53:33 2023 Received: (at 64819) by debbugs.gnu.org; 3 Sep 2023 19:53:34 +0000 Received: from localhost ([127.0.0.1]:46973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qctA5-0006d5-6K for submit@debbugs.gnu.org; Sun, 03 Sep 2023 15:53:33 -0400 Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:45507) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qctA0-0006cl-Tv for 64819@debbugs.gnu.org; Sun, 03 Sep 2023 15:53:31 -0400 Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-40061928e5aso7975895e9.3 for <64819@debbugs.gnu.org>; Sun, 03 Sep 2023 12:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693770803; x=1694375603; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=/bxdHGNg4qn5eg+x7NxHXnu3bM6Z7++ei+sxYdk+pTM=; b=i6UnSFG7gtLZAZhiZfVkjvZ+Gq5jFj7haaBavqcfz5444OICFTWUWiZHcpYZ3kk/wV LpBcpi7pFP1XtZK76Pz31QUmA1iCPTLRbceOEE39LbW5HcSFA8B4zL1Cghn26KzgvRm9 0QhmGZ+h7r85q3l7h/PiQqnXTJNa0FUwJ5M6fKSXO+Zy3o7A9uh2MPv7odxyJKynfdE3 zc9s9C6ftze3gp2dIi9M94dMCj+JoGSMRYY6f6Vd/bKrrC9+cQJDqZQxVkTJJoAUfeW/ mfE1aEQiWZhrenAhJGrjG2oUoBDH3dJbJWEBvGrJZPKyk1fbuzq6JHDBQYxNo7k7qlU+ QWnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693770803; x=1694375603; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/bxdHGNg4qn5eg+x7NxHXnu3bM6Z7++ei+sxYdk+pTM=; b=Jp7JTzH8rABmHL7Zjih40VLZe8u8wzihf9v52RmABCFKVDSEMTiOv6LjilqUfyYh37 HV4Ocvura3D8z8Qx7oT5PFJRGWxtf/bAySibr/taHCe0MOcHX68t8EZ6oC7jrxnm+x99 WVnC5F0GaGqc3+nKvaH3Ccu4KaKx44mgUu1AnHlOo5zcJFCImoxVKVpdDdo6wuRJDRPe df4bwqhc0GjpVj2mCfDEcg0cL/Lc0Y/HAaKFpwYmfkTXVtBeulVYn5geqodP909FoV+M TKHEByTMuJx2jqQttWqXwc3wODHlMLJl1zXB39Xm3iSAaVxpehLotmLMmi8+4DiTwjia VAlA== X-Gm-Message-State: AOJu0YwMJBq07jFJFAFpDqzC7hRjXmc4O/esncfLMJ2yaKVnZZtl9ijC 7tMTSeNzgJCR9zypep6p/rpBB4DQwu4= X-Google-Smtp-Source: AGHT+IHtWH+zbV6vQsGBL6F+ofMorr2CpjUaqKWkfrm5l+r2IzX8sX+nrZOscnSRcMWwciaK3+DE8w== X-Received: by 2002:a05:600c:2117:b0:401:d3dd:c3c with SMTP id u23-20020a05600c211700b00401d3dd0c3cmr5389064wml.39.1693770803191; Sun, 03 Sep 2023 12:53:23 -0700 (PDT) Received: from caladan ([31.177.119.112]) by smtp.gmail.com with ESMTPSA id f7-20020adffcc7000000b0031c7682607asm12502852wrs.111.2023.09.03.12.53.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Sep 2023 12:53:22 -0700 (PDT) From: Helmut Eller To: Stefan Kangas Subject: Re: bug#64819: 30.0.50; condition-wait not interruptible In-Reply-To: (Stefan Kangas's message of "Sat, 2 Sep 2023 14:58:27 -0700") References: <83pm4hse6n.fsf@gnu.org> <838rb5saau.fsf@gnu.org> <83r0oxqnwc.fsf@gnu.org> <83351cqj56.fsf@gnu.org> Date: Sun, 03 Sep 2023 21:53:21 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64819 Cc: Eli Zaretskii , 64819@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: -1.0 (-) --=-=-= Content-Type: text/plain On Sat, Sep 02 2023, Stefan Kangas wrote: > Did you get any further with this? Well, a bit. I'm currently using the attached patch and for testing the attached shell script. The patch is good enough to pass these tests. I don't know if it breaks something else. I had to change maybe_reacquire_global_lock to make the tests pass. The idea behind maybe_reacquire_global_lock seems dubious: waiting for a lock in a signal handler seems, well, problematic. Anyway, the patch is work in progress and only useful to me. (The patch also includes changes for Windows, but I only tested those manually and under Wine. For the Windows console version, C-g doesn't interrupt condition-wait. Ordinary endless loops don't seem be interruptible there either. So, maybe this is acceptable.) Helmut --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=interruptible-condition-wait.patch diff --git a/src/keyboard.c b/src/keyboard.c index 6ab1cdebc12..d8262c779c2 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -8099,6 +8099,11 @@ handle_input_available_signal (int sig) if (input_available_clear_time) *input_available_clear_time = make_timespec (0, 0); + +#ifdef THREADS_ENABLED + maybe_reacquire_global_lock (); + maybe_awake_current_thread (); +#endif } static void @@ -12076,7 +12081,10 @@ handle_interrupt (bool in_signal_handler) thread, see deliver_process_signal. So we must make sure the main thread holds the global lock. */ if (in_signal_handler) - maybe_reacquire_global_lock (); + { + maybe_reacquire_global_lock (); + maybe_awake_current_thread (); + } #endif if (waiting_for_input && !echoing) quit_throw_to_read_char (in_signal_handler); diff --git a/src/process.c b/src/process.c index 08cb810ec13..a25071a482a 100644 --- a/src/process.c +++ b/src/process.c @@ -5473,7 +5473,8 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd, update_status (wait_proc); if (wait_proc && ! EQ (wait_proc->status, Qrun) - && ! connecting_status (wait_proc->status)) + && ! connecting_status (wait_proc->status) + && ! EQ (wait_proc->status, Qlisten)) { bool read_some_bytes = false; diff --git a/src/systhread.c b/src/systhread.c index caa4dfd4443..fa652abbb30 100644 --- a/src/systhread.c +++ b/src/systhread.c @@ -273,6 +273,9 @@ sys_thread_yield (void) #include #include "w32term.h" +/* From w32xfns.c */ +extern HANDLE interrupt_handle; + /* Cannot include because of the local header by the same name, sigh. */ uintptr_t _beginthread (void (__cdecl *)(void *), unsigned, void *); @@ -310,7 +313,9 @@ sys_cond_init (sys_cond_t *cond) cond->events[CONDV_SIGNAL] = CreateEvent (NULL, FALSE, FALSE, NULL); /* Manual-reset event for broadcast. */ cond->events[CONDV_BROADCAST] = CreateEvent (NULL, TRUE, FALSE, NULL); - if (!cond->events[CONDV_SIGNAL] || !cond->events[CONDV_BROADCAST]) + cond->events[CONDV_INTERRUPT] = interrupt_handle; + if (!cond->events[CONDV_SIGNAL] || !cond->events[CONDV_BROADCAST] + || !cond->events[CONDV_INTERRUPT]) return; InitializeCriticalSection ((LPCRITICAL_SECTION)&cond->wait_count_lock); cond->initialized = true; @@ -333,15 +338,15 @@ sys_cond_wait (sys_cond_t *cond, sys_mutex_t *mutex) /* Release the mutex and wait for either the signal or the broadcast event. */ LeaveCriticalSection ((LPCRITICAL_SECTION)mutex); - wait_result = WaitForMultipleObjects (2, cond->events, FALSE, INFINITE); + wait_result + = WaitForMultipleObjects (CONDV_MAX, cond->events, FALSE, INFINITE); /* Decrement the wait count and see if we are the last thread waiting on the condition variable. */ EnterCriticalSection ((LPCRITICAL_SECTION)&cond->wait_count_lock); cond->wait_count--; - last_thread_waiting = - wait_result == WAIT_OBJECT_0 + CONDV_BROADCAST - && cond->wait_count == 0; + last_thread_waiting = wait_result == WAIT_OBJECT_0 + CONDV_BROADCAST + && cond->wait_count == 0; LeaveCriticalSection ((LPCRITICAL_SECTION)&cond->wait_count_lock); /* Broadcast uses a manual-reset event, so when the last thread is diff --git a/src/systhread.h b/src/systhread.h index b8f078df071..7e9ac83f951 100644 --- a/src/systhread.h +++ b/src/systhread.h @@ -55,7 +55,13 @@ typedef struct { unsigned long SpinCount; } w32thread_critsect; -enum { CONDV_SIGNAL = 0, CONDV_BROADCAST = 1, CONDV_MAX = 2 }; +enum +{ + CONDV_SIGNAL = 0, + CONDV_BROADCAST = 1, + CONDV_INTERRUPT = 2, + CONDV_MAX = 3 +}; typedef struct { /* Count of threads that are waiting for this condition variable. */ diff --git a/src/thread.c b/src/thread.c index b8ca56fd372..efe21702b5f 100644 --- a/src/thread.c +++ b/src/thread.c @@ -158,21 +158,46 @@ acquire_global_lock (struct thread_state *self) void maybe_reacquire_global_lock (void) { + eassert (sys_thread_equal (sys_thread_self (), main_thread.s.thread_id)); + /* SIGINT handler is always run on the main thread, see deliver_process_signal, so reflect that in our thread-tracking variables. */ - current_thread = &main_thread.s; + struct thread_state *self = &main_thread.s; - if (current_thread->not_holding_lock) + if (self->not_holding_lock) { - struct thread_state *self = current_thread; - acquire_global_lock (self); - current_thread->not_holding_lock = 0; + self->not_holding_lock = 0; + eassert (current_thread == self); } + + if (current_thread == NULL) + post_acquire_global_lock (self); + + eassert (!self->not_holding_lock); + eassert (current_thread != NULL); } - +/* This is called from keyboard.c when it sets pending_signals=true. + If the current thread is waiting, we create a spurious wakeup by + broadcasting on wait_condvar. This is necessary because + pthread_cond_wait may or may not return if it was interrupted by a + signal (SIGIO). Without the wakeup, nobody would process a + potential C-g. +*/ +void +maybe_awake_current_thread (void) +{ + eassert (sys_thread_equal (sys_thread_self (), main_thread.s.thread_id)); + eassert (!main_thread.s.not_holding_lock); + eassert (current_thread != NULL); + + struct thread_state *t = current_thread; + + if (t->wait_condvar != NULL) + sys_cond_broadcast (t->wait_condvar); +} static void lisp_mutex_init (lisp_mutex_t *mutex) diff --git a/src/thread.h b/src/thread.h index 9b14cc44f35..60f601a6248 100644 --- a/src/thread.h +++ b/src/thread.h @@ -311,6 +311,7 @@ extern void finalize_one_thread (struct thread_state *state); extern void finalize_one_mutex (struct Lisp_Mutex *); extern void finalize_one_condvar (struct Lisp_CondVar *); extern void maybe_reacquire_global_lock (void); +extern void maybe_awake_current_thread (void); extern void init_threads (void); extern void syms_of_threads (void); --=-=-= Content-Type: text/x-sh Content-Disposition: attachment; filename=cnd-wait-test.sh #!/bin/bash # Test whether condition-wait is interruptible by C-g. # # This script requires two tools: xdotool and dotool. # # xdotool: is included in Debian # # dotool: I installed it manually from https://git.sr.ht/~geb/dotool. # As dotool requires permissions to access /dev/input, I use sudo to # run it. # # The script output follows TAP syntax (https://testanything.org/) and # could be parsed for example with prove(1). set -o errexit # Ask sudo password now and remember it for later sudo dotool --version >/dev/null TMPFILE=$(mktemp) TESTNR=0 function check { local PROG="$1" FUN="$2" READYMSG="$3" $PROG -Q -l wait.el --eval "($FUN \"$TMPFILE\")" & local EMACSPID=$! trap "rm -f $TMPFILE; kill $EMACSPID 2>/dev/null || :" EXIT # Wait until Emacs is ready until [ "$(cat $TMPFILE)" == "$READYMSG" ] ; do sleep 0.2 done # Set focus on Emacs xdotool search --sync --onlyvisible --all \ --pid $EMACSPID --name '' windowfocus # Send C-g to input device echo 'key ctrl+g' | sudo dotool wait $EMACSPID DESC="$TESTNR - $PROG $FUN" case "$(cat $TMPFILE)" in QUIT | QUIT1 | QUIT2) echo ok $DESC;; *) cat $TMPFILE >2 echo not ok $DESC ;; esac } declare -a PROGS PROGS=(emacs 'xterm -e emacs -nw') declare -A READYMSGS READYMSGS=( [wait-forever]=WAITING [spawn-child-then-wait]='WAITING1 TERMINATING2' [two-threads-waiting]='WAITING1 WAITING2' ) echo 1..$((${#PROGS[@]} * ${#READYMSGS[@]})) for prog in "${PROGS[@]}" ; do for fun in "${!READYMSGS[@]}" ; do TESTNR=$(($TESTNR + 1)) check "$prog" $fun "${READYMSGS[$fun]}" done done --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=wait.el ;; -*- lexical-binding:t -*- (defun wait-forever (filename) (unwind-protect (condition-case e (let* ((mutex (make-mutex)) (cvar (make-condition-variable mutex))) (with-mutex mutex (write-region "WAITING" nil filename nil 0) (while t (condition-wait cvar)))) (quit (write-region "QUIT" nil filename nil 0))) (kill-emacs))) (defun spawn-child-then-wait (filename) (make-thread (lambda () (write-region " TERMINATING2" nil filename t 0))) (unwind-protect (condition-case e (let* ((mutex (make-mutex)) (cvar (make-condition-variable mutex))) (with-mutex mutex (write-region "WAITING1" nil filename nil 0) (while t (condition-wait cvar)))) (quit (write-region "QUIT1" nil filename nil 0))) (kill-emacs))) (defun two-threads-waiting (filename) (make-thread (lambda () (unwind-protect (condition-case e (let* ((mutex (make-mutex)) (cvar (make-condition-variable mutex))) (with-mutex mutex (write-region " WAITING2" nil filename t 0) (while t (condition-wait cvar)))) (quit (write-region "QUIT2" nil filename nil 0))) (kill-emacs)))) (unwind-protect (condition-case e (let* ((mutex (make-mutex)) (cvar (make-condition-variable mutex))) (with-mutex mutex (write-region "WAITING1" nil filename nil 0) (while t (condition-wait cvar)))) (quit (write-region " QUIT1" nil filename t 0))) (kill-emacs))) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 06 05:35:16 2023 Received: (at 64819) by debbugs.gnu.org; 6 Sep 2023 09:35:16 +0000 Received: from localhost ([127.0.0.1]:32964 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdowO-00016B-CS for submit@debbugs.gnu.org; Wed, 06 Sep 2023 05:35:16 -0400 Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]:61549) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdowJ-00015t-G1 for 64819@debbugs.gnu.org; Wed, 06 Sep 2023 05:35:14 -0400 Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-4ff09632194so5896875e87.2 for <64819@debbugs.gnu.org>; Wed, 06 Sep 2023 02:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693992904; x=1694597704; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=Nxy6+G2y+Z33neBDK+EJDB54ItJQ4o4NRus9p/Cu2Ls=; b=gvIoQe5DMwP+f3i8XJUXgK0vd7RGYhmCNatxgbPXdvwjAHRDaAruz3G6gXVBh8gVph bcHS3O4SA05E8lsc5kAFxDoAvEP1x5L0NAyUqXRF6o8OV9sSEcmco4A0XieAdLzkVFSr 7oMubEHVHWKQG4VYtIPhctW41fWkTwyRvwHqcpoUbyF6Yc3V9YynHu0VkKOsfQYID2F7 To+ljwstRsS1e4VhMzeM561ebT4i/Yjv5/L5G/6PsP0STGiQn7uqV5JxCPcgBpNFF+B4 oqhCh0HZtmxMfVH3jw4C40o8FgvIgcXAPVqILQOZV53r60yrcMIBqq3EA37OdiSWnSCd AvtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693992904; x=1694597704; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Nxy6+G2y+Z33neBDK+EJDB54ItJQ4o4NRus9p/Cu2Ls=; b=di/gW8ImNZ5DppYgst0uWEu0+qDrEVW/ARbn2MfS9JWcrkkDl4jZKiEpkYUJLCyCeb qAPvCtrgWgwL49QpCpA8zMYaGjUZIHvQGCF5h+AcDo7S7VjuCSlH0NYF+Ath5RgPl+WI XP2VWf6w3ASor5LlT/j72PfLtpP2K+AP/Jinbf9//9oyrtdulJbUukU17kDU89mlvnqS qkQ7R8zklAM07jSxgYWyxMNatB6OAimv6v77IEACBGn59aGUc9rU5R2Op08Y0gaaO1eu +8pj/Nou5kBwNrCyKpmq9J/30/C9cI1DA+VfxO06+DY6Z4lh/W2nirh4PybWo8oFf42x 182A== X-Gm-Message-State: AOJu0Yz8Q8S9cDO2i/RC0oYmWdKu0Wd5Q0gLsPTw0UQiSeDl5fZGOgj4 bHC9Azy37dJ9kiAxcwyDlVL6sIZUW0r+dLtyoj3b7u0pUvQ= X-Google-Smtp-Source: AGHT+IHb0LclSwbSc7kLAN999ozccNKv7aZIbD6buoFkjnwuMhudYm7zGcgJXSwIN7BDwCs0i4GV5OVYvT34DteNc3g= X-Received: by 2002:a05:6512:3e0f:b0:500:7a23:720b with SMTP id i15-20020a0565123e0f00b005007a23720bmr2238275lfv.55.1693992903825; Wed, 06 Sep 2023 02:35:03 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Wed, 6 Sep 2023 02:35:03 -0700 From: Stefan Kangas In-Reply-To: References: <83pm4hse6n.fsf@gnu.org> <838rb5saau.fsf@gnu.org> <83r0oxqnwc.fsf@gnu.org> <83351cqj56.fsf@gnu.org> MIME-Version: 1.0 Date: Wed, 6 Sep 2023 02:35:03 -0700 Message-ID: Subject: Re: bug#64819: 30.0.50; condition-wait not interruptible To: Helmut Eller Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64819 Cc: Eli Zaretskii , 64819@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: -1.0 (-) Helmut Eller writes: > Anyway, the patch is work in progress and only useful to me. Thanks, it's good to see that you're still working on this. Please do let us know when you have something that you feel is closer to being ready for install. I'll leave commenting on your patch to other people, as I'm not familiar with this code.