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#64819: 30.0.50; condition-wait not interruptible Date: Mon, 24 Jul 2023 19:23:31 +0300 Message-ID: <83r0oxqnwc.fsf@gnu.org> References: <83pm4hse6n.fsf@gnu.org> <838rb5saau.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2988"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 64819@debbugs.gnu.org To: Helmut Eller Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 24 18:23:20 2023 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 1qNyLA-0000YD-96 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 24 Jul 2023 18:23:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qNyKu-0002CM-1p; Mon, 24 Jul 2023 12:23:04 -0400 Original-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 1qNyKt-0002CE-0d for bug-gnu-emacs@gnu.org; Mon, 24 Jul 2023 12:23:03 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qNyKs-0008O2-PR for bug-gnu-emacs@gnu.org; Mon, 24 Jul 2023 12:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qNyKs-0004bb-2O for bug-gnu-emacs@gnu.org; Mon, 24 Jul 2023 12:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Jul 2023 16:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64819 X-GNU-PR-Package: emacs Original-Received: via spool by 64819-submit@debbugs.gnu.org id=B64819.169021578117696 (code B ref 64819); Mon, 24 Jul 2023 16:23:02 +0000 Original-Received: (at 64819) by debbugs.gnu.org; 24 Jul 2023 16:23:01 +0000 Original-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 Original-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 Original-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==; Original-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 In-Reply-To: (message from Helmut Eller on Mon, 24 Jul 2023 16:57:05 +0200) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:265982 Archived-At: > 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.