Received: (at 80286) by debbugs.gnu.org; 8 Feb 2026 18:07:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 08 13:07:57 2026 Received: from localhost ([127.0.0.1]:54217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vp9CO-0006Nc-NC for submit <at> debbugs.gnu.org; Sun, 08 Feb 2026 13:07:57 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51022) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vp9CM-0006Mq-RK for 80286 <at> debbugs.gnu.org; Sun, 08 Feb 2026 13:07:55 -0500 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 <eliz@HIDDEN>) id 1vp9CH-000886-C9; Sun, 08 Feb 2026 13:07:49 -0500 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=7MqgwyT5C9vpmZC44BKWYYZNGUqErYjcOLROLcAkDN0=; b=TGl1JLB1Qj20 vk8inGgOmtZkCUoS+Gg/oHJl7NovjLkKYntL9mKKjFGqYHbsQ24iuAPqNAVRLfCfuig5iKoaBjK7t 5GvIkqPNwUuUHPe4X62SPN+e54Ho/lHBYa1m+EvnSVdnB/ep+QRZPgMyK6ocEJr3l4AlkRan+5/PS S0HS2CGyRk7/F+XRGYnYWpP/L/tPmcFGG6iUWTQMJM7YlhheEu+FuDm1QkL91piIOBvFrulbO5tz5 K39A2xt8mektezWaENChSVUHM2HdkjiUuvOX5dlSTTXQUIrLPd4wfYqKJGgtky+MUAWXjSC2DkcAX oQ8KPYgVzZ+C2JisLuRjHw==; Date: Sun, 08 Feb 2026 20:07:38 +0200 Message-Id: <861pivt8gl.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwv8qd3425u.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sun, 08 Feb 2026 11:46:19 -0500) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <c717c2e5-f0bf-47c0-b9b6-a8bd5dfe6203@HIDDEN> <jwvldh9u7n1.fsf-monnier+emacs@HIDDEN> <93e69553-aad9-4ff4-9190-cd3671b1897b@HIDDEN> <jwvh5rwbi1d.fsf-monnier+emacs@HIDDEN> <1904dc62-6bcc-4ef7-b586-6ebc0cf37d71@HIDDEN> <86ms1mw9s0.fsf@HIDDEN> <jwv1piv5jzt.fsf-monnier+emacs@HIDDEN> <868qd3tdey.fsf@HIDDEN> <jwv8qd3425u.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: dmitry@HIDDEN, 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: dmitry@HIDDEN, 80286 <at> debbugs.gnu.org, johnw@HIDDEN > Date: Sun, 08 Feb 2026 11:46:19 -0500 > > >> (run-with-timer delay nil > >> (lambda () > >> (with-mutex m (condition-notify c)))) > >> > >> with something like > >> > >> (schedule-timer-event delay nil c) > >> > >> [ Of course, there are lots of question marks here. I was describing > >> some very vague idea. ] > > > > I understand the idea, I just don't understand how can it be > > implemented, as long as our Lisp threads work as they do. A timer > > must run in some Lisp thread, > > No: if you look above, the `schedule-timer-event` does not provide any > ELisp code to run after DELAY. I understood that. It needs to cause some Lisp thread start running. I'm talking about the implementation of "cause some Lisp thread start running". > It provides only a condvar C. So, all it requires is the ability to > notify a condvar without having the global ELisp lock. That's a > much lower bar than running arbitrary ELisp code. That's the condition-wait with a timeout which I proposed to respin at the very beginning of this discussion.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 8 Feb 2026 16:46:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 08 11:46:31 2026 Received: from localhost ([127.0.0.1]:52960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vp7va-00027U-NI for submit <at> debbugs.gnu.org; Sun, 08 Feb 2026 11:46:31 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:15889) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vp7vX-00026y-HX for 80286 <at> debbugs.gnu.org; Sun, 08 Feb 2026 11:46:28 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7BB27100034; Sun, 8 Feb 2026 11:46:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1770569180; bh=NINZ+cFA2OM0scqQhF8h0+xXFWNghUfHkVzAWymMalw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=UY5lEiCsboqhRZIRmm+UKM/Kuu6Pdz9+7287nI+A0I5zkj4qxHly+B+8auqlIATwf YlDR8GYrLVjJx+hhhYd+W+KsDaAO0zMJ/A4sDTH8FRyoStTMi4Xc2G1rdg6w928cH3 IjY23mZW+0fqVLc9GkP3CWA1eTr6h4rCmAv7PcxHJ83nopCI7bV+XDIlqgbmXLfDlA eXDuXgJIRcI9h07xBQWPtiAG2XFMu+MenBYr+5n4BRxf7Ttli0Ly37LPnFaswBmA2d ijVQp0mPtwTj64clMT0wPqdODTM6ctl/YMbU8aLJHIN+TegGklGIZDkjDcVCxYUnPS 3s3Ad6ybwc8pw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 949D5100029; Sun, 8 Feb 2026 11:46:20 -0500 (EST) Received: from pastel (104-195-243-38.cpe.teksavvy.com [104.195.243.38]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5AEE8120B9C; Sun, 8 Feb 2026 11:46:20 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers In-Reply-To: <868qd3tdey.fsf@HIDDEN> Message-ID: <jwv8qd3425u.fsf-monnier+emacs@HIDDEN> References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <c717c2e5-f0bf-47c0-b9b6-a8bd5dfe6203@HIDDEN> <jwvldh9u7n1.fsf-monnier+emacs@HIDDEN> <93e69553-aad9-4ff4-9190-cd3671b1897b@HIDDEN> <jwvh5rwbi1d.fsf-monnier+emacs@HIDDEN> <1904dc62-6bcc-4ef7-b586-6ebc0cf37d71@HIDDEN> <86ms1mw9s0.fsf@HIDDEN> <jwv1piv5jzt.fsf-monnier+emacs@HIDDEN> <868qd3tdey.fsf@HIDDEN> Date: Sun, 08 Feb 2026 11:46:19 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.192 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: dmitry@HIDDEN, 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) >> (run-with-timer delay nil >> (lambda () >> (with-mutex m (condition-notify c)))) >> >> with something like >> >> (schedule-timer-event delay nil c) >> >> [ Of course, there are lots of question marks here. I was describing >> some very vague idea. ] > > I understand the idea, I just don't understand how can it be > implemented, as long as our Lisp threads work as they do. A timer > must run in some Lisp thread, No: if you look above, the `schedule-timer-event` does not provide any ELisp code to run after DELAY. It provides only a condvar C. So, all it requires is the ability to notify a condvar without having the global ELisp lock. That's a much lower bar than running arbitrary ELisp code. === Stefan
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 8 Feb 2026 16:20:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 08 11:20:52 2026 Received: from localhost ([127.0.0.1]:52523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vp7Wl-0008Fz-QJ for submit <at> debbugs.gnu.org; Sun, 08 Feb 2026 11:20:52 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50134) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vp7Wj-0008FM-19 for 80286 <at> debbugs.gnu.org; Sun, 08 Feb 2026 11:20:50 -0500 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 <eliz@HIDDEN>) id 1vp7Wd-0004vh-9l; Sun, 08 Feb 2026 11:20:43 -0500 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=D0N5n5I3jeF7iNIcJ4Y/FFSju9k/9nUud5UZTbY8npk=; b=ip0jyYq90DjP 1kL8mnPbSkEC41l78jLU2eXkdR/AlIzTGWdUpxGrus/xDDoFQ+MmzVTC+jPpH0dv+1LLzWfrth0/s O6oo5JBqp5F9Tqpr4PlSqaPKM7K064eM75jdtooHYtEKbKiZlwO5p49kSsmZkbvPiovpsUiG+5no0 FiZa9F41CaLu8+dSDKDr7Ax3ObendpWo8QbeOhDcykeozQaVg8TsJ3F11F7mIXrRUtO+E7FrW4IG+ O/5b8YLHLuoqMTKbP7ndqVHvXizCFRNpCGyYqt/PKGGEtXIZwh+V5ebxh1IZrxs9gl8DT3JPEooVx 2iFHRObspbujK85O/14r1A==; Date: Sun, 08 Feb 2026 18:20:37 +0200 Message-Id: <868qd3tdey.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwv1piv5jzt.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sun, 08 Feb 2026 10:47:09 -0500) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <c717c2e5-f0bf-47c0-b9b6-a8bd5dfe6203@HIDDEN> <jwvldh9u7n1.fsf-monnier+emacs@HIDDEN> <93e69553-aad9-4ff4-9190-cd3671b1897b@HIDDEN> <jwvh5rwbi1d.fsf-monnier+emacs@HIDDEN> <1904dc62-6bcc-4ef7-b586-6ebc0cf37d71@HIDDEN> <86ms1mw9s0.fsf@HIDDEN> <jwv1piv5jzt.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: dmitry@HIDDEN, 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: Dmitry Gutov <dmitry@HIDDEN>, 80286 <at> debbugs.gnu.org, johnw@HIDDEN > Date: Sun, 08 Feb 2026 10:47:09 -0500 > > > Personally, I don't understand how an internal C thread that is not > > synchronized with the global lock, could schedule timers. Timers > > generally run Lisp code, so this would mean we allow two separate > > threads to run Lisp simultaneously, which will never work well. > > Or what am I missing? > > "Schedule timers" doesn't mean "run timer's code". > > E.g. in my original sample code, I could replace > > (run-with-timer delay nil > (lambda () > (with-mutex m (condition-notify c)))) > > with something like > > (schedule-timer-event delay nil c) > > [ Of course, there are lots of question marks here. I was describing > some very vague idea. ] I understand the idea, I just don't understand how can it be implemented, as long as our Lisp threads work as they do. A timer must run in some Lisp thread, and if no Lisp thread is running or expected to be run soon, there's nothing to run the timer. If the only thread which exists is stuck waiting for an event that won't happen, we are toast, and I don't see how schedule-timer-event could be implemented, unless we completely change how the threads work and how they are "scheduled". > > How will this work? We can only "wake" a thread if we stop another one, > > I think the idea of `thread-resume` is not to make that other thread run > *now* (like what happens with coroutines) but to just mark it as being > ready to run. > > But yes, that means a change of semantics of `thread-yield` from just letting > some other thread run to putting itself to indefinite sleep (until > some other thread explicitly wakes up the original thread with > `thread-resume`). > > We can already provide that behavior with `condition-wait` and > `condition-notify`. Right.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.
Received: (at 80286) by debbugs.gnu.org; 8 Feb 2026 15:47:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 08 10:47:20 2026
Received: from localhost ([127.0.0.1]:52087 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vp70K-0004u2-8E
for submit <at> debbugs.gnu.org; Sun, 08 Feb 2026 10:47:20 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:14275)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vp70H-0004t5-Kr
for 80286 <at> debbugs.gnu.org; Sun, 08 Feb 2026 10:47:18 -0500
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8DABE81BB1;
Sun, 8 Feb 2026 10:47:11 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1770565630;
bh=tae6W3zhPd1PgLyhSNKu59Zm2cVpIiv5++aXTTVeuo0=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=JAUGuXwljhLbUqbj6/NkBR7p3aFo6wRccdfVk/R0fvsLg0UxozmINVtdB+Vg0lEKO
ErgTOjdvf11bmSGyx578cLVz9wixbOjEeKF+3F4MZz+tmo85w5zr16Oi0gzryDMZAz
Wf9S17bnHXMkgDXteJappx197yOq7ps6Iq8v466UocdMvC3ONTPJ/jXnr/LX3WDKTb
TeL5q56yeXihjDubsl52XvqivL3xb8TZwE2dmq0P4a1FA07+luf65N7zMxydwxiBKK
KJMNlLh+6HF07Nd8ed5TiQbNHm7bBCALzJCmODQK0R8HNrwrDh1MIsXUmlJyIARUsG
GG+etsxqZLkxw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id ACA13817DA;
Sun, 8 Feb 2026 10:47:10 -0500 (EST)
Received: from pastel (104-195-243-38.cpe.teksavvy.com [104.195.243.38])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 638751207B3;
Sun, 8 Feb 2026 10:47:10 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers
In-Reply-To: <86ms1mw9s0.fsf@HIDDEN>
Message-ID: <jwv1piv5jzt.fsf-monnier+emacs@HIDDEN>
References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN>
<jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN>
<jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN>
<86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN>
<861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN>
<jwv4io0h63j.fsf-monnier+emacs@HIDDEN>
<c717c2e5-f0bf-47c0-b9b6-a8bd5dfe6203@HIDDEN>
<jwvldh9u7n1.fsf-monnier+emacs@HIDDEN>
<93e69553-aad9-4ff4-9190-cd3671b1897b@HIDDEN>
<jwvh5rwbi1d.fsf-monnier+emacs@HIDDEN>
<1904dc62-6bcc-4ef7-b586-6ebc0cf37d71@HIDDEN>
<86ms1mw9s0.fsf@HIDDEN>
Date: Sun, 08 Feb 2026 10:47:09 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.140 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80286
Cc: Dmitry Gutov <dmitry@HIDDEN>, 80286 <at> debbugs.gnu.org, johnw@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Personally, I don't understand how an internal C thread that is not
> synchronized with the global lock, could schedule timers. Timers
> generally run Lisp code, so this would mean we allow two separate
> threads to run Lisp simultaneously, which will never work well.
> Or what am I missing?
"Schedule timers" doesn't mean "run timer's code".
E.g. in my original sample code, I could replace
(run-with-timer delay nil
(lambda ()
(with-mutex m (condition-notify c))))
with something like
(schedule-timer-event delay nil c)
[ Of course, there are lots of question marks here. I was describing
some very vague idea. ]
> How will this work? We can only "wake" a thread if we stop another one,
I think the idea of `thread-resume` is not to make that other thread run
*now* (like what happens with coroutines) but to just mark it as being
ready to run.
But yes, that means a change of semantics of `thread-yield` from just letting
some other thread run to putting itself to indefinite sleep (until
some other thread explicitly wakes up the original thread with
`thread-resume`).
We can already provide that behavior with `condition-wait` and
`condition-notify`.
=== Stefan
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 8 Feb 2026 07:21:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 08 02:21:58 2026 Received: from localhost ([127.0.0.1]:44335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1voz7D-0004IV-6r for submit <at> debbugs.gnu.org; Sun, 08 Feb 2026 02:21:58 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59614) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1voz79-0004H9-RI for 80286 <at> debbugs.gnu.org; Sun, 08 Feb 2026 02:21:53 -0500 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 <eliz@HIDDEN>) id 1voz73-00034f-2E; Sun, 08 Feb 2026 02:21:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=cdtVF+/Ws9o3Qa0Cr+sy3eA+2zaVtZKi5ag2d3l9iKM=; b=M1Z2xCbxvAwgW+mujfbV VR9Yx4VbQlyV+NbWHMa2hIJZmzhoSLmJQeSaZNxjuJaYluKtSWXkKnV1heeHJCXYtIHEkPxHfx93R CbyUd5OUXEziJDfjFeUAJVNX+rgBKmgkbO3MnUzxxT3w/qZXcMaSRPzX7iuVr6IESbP2cYdhwkawj pL/+j1AOFE97uOaN2vx0q0+3sNTinhGYrtLW09Bcnh2O8+X/+PT2T7YfC5jXkDFIjhgT++ljtXuVV UOsDZT6ltx45dd+mH9riq1Fgr0BK0AnOIx72NCtBb1ZahCWXAm55PSn4ZHAmhB4NY7I3tCj/+2UQQ AKRjieRclfpxzA==; Date: Sun, 08 Feb 2026 09:21:42 +0200 Message-Id: <86tsvru2d5.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <0ba4200b-d166-4cb1-aece-605f88522649@HIDDEN> (message from Dmitry Gutov on Sun, 8 Feb 2026 02:20:17 +0200) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <c717c2e5-f0bf-47c0-b9b6-a8bd5dfe6203@HIDDEN> <jwvldh9u7n1.fsf-monnier+emacs@HIDDEN> <93e69553-aad9-4ff4-9190-cd3671b1897b@HIDDEN> <jwvh5rwbi1d.fsf-monnier+emacs@HIDDEN> <1904dc62-6bcc-4ef7-b586-6ebc0cf37d71@HIDDEN> <86ms1mw9s0.fsf@HIDDEN> <78937e00-d99f-4a65-9b20-e96242fc4c60@HIDDEN> <864intvse8.fsf@HIDDEN> <0ba4200b-d166-4cb1-aece-605f88522649@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, monnier@HIDDEN, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sun, 8 Feb 2026 02:20:17 +0200 > Cc: monnier@HIDDEN, 80286 <at> debbugs.gnu.org, johnw@HIDDEN > From: Dmitry Gutov <dmitry@HIDDEN> > > On 07/02/2026 11:01, Eli Zaretskii wrote: > > >> IIUC the idea is just to be able to wake the waiting thread without > >> having to allocate another thread to run the timer or sentinel, by > >> annotating the said timer or sentinel, with knowledge that they should > >> wake a specific thread. > > > > How will this work? We can only "wake" a thread if we stop another > > one, and do that in a way that is safe wrt the state of the Lisp > > machine. The call to thread_select does that, but it is written on > > the assumption that it's called by the thread which will be stopped, > > not by some other thread. > > > >> Or IOW the goal would be to be able to use condition vars with just a > >> single Lisp thread. > > > > What could be the use of a condvar when there's just one thread? The > > only use I can see is that the condition-wait exists immediately, > > perhaps with some error indication. To do that, we don't need any > > complications like an additional C thread. > > (To comment on both paragraphs.) > > I don't know. Maybe the main thread should never run alone. Or maybe the > "waker" code should have its own rhythms (probably running on a separate > native thread) and itself do scheduling of Lisp threads to handle > pending process output, timers, etc, see below (that would be a big > change, though). This is very different from what we have. We don't schedule threads ourselves, we let the system do that, and we use synchronization primitives to make sure only one thread can run the Lisp machine at any given time. > IIUC at the base it is an evented system which is based on tasks and > registered callbacks. When an event arrives, there must be a saved > reference to the callback which has to be run. Depending on the exact > system I suppose the callback could be a function in high level code > (Ruby/Lisp/JS), or it could just be a bit of information about which > thread to wake. > > The programs I'm talking about are not text editors so there's bound to > be some mismatch, but the pattern I'm referring to is called Reactor. > > Here's a small quote from an article: > > If you have ever used Node.js, you are familiar with the concept of an > event loop. The Reactor is essentially a continuous loop that monitors > various I/O sources—like network sockets or file descriptors—to see if > they are ready for reading or writing. Instead of a thread sitting > idle and "blocking" while waiting for a database to respond, the > Reactor puts that specific task to sleep and moves on to the next task > in the queue. > > When the database finally responds, the Reactor receives a > notification from the operating system, finds the task that was > waiting for that data, and resumes it exactly where it left off. > Because this happens inside a single thread [...elided...], the > overhead is incredibly low. The async gem provides a > clean Ruby implementation of this Reactor, allowing you to manage > thousands of concurrent connections without the memory bloat of > thousands of OS threads. > > This was about the latest implementation of that pattern. > > 10-15 years ago there was another popular library called EventMachine. > Here is a description of it, with diagrams: > https://deepwiki.com/eventmachine/eventmachine > > This one just has an event reactor but no direct support for green > threads (fibers). The latter plug in by a separate library on top of the > reactor, roughly like this: when a fiber needs to do a blocking > operation, it sets up a callback for that operation's completion (and > maybe callbacks for streaming, e.g. for a network response), and then > yields execution. When corresponding events arrive, the reactor looks up > which callbacks are registered with them, executes the callbacks (in > application code, this would be Lisp code in our case), and among them > the callback which wakes the fiber, allowing it to process the newly > arrived data. This is also completely different from what we have. The current implementation explicitly avoids dealing with scheduling and managing threads. It's okay to talk about redesigning and reimplementing Lisp threads in a completely different fashion, but we must realize that this is the essence of what you propose (and the bug tracker is not the place to discuss this, IMO).
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 8 Feb 2026 00:20:33 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 07 19:20:32 2026 Received: from localhost ([127.0.0.1]:40914 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vosXQ-0003E0-5C for submit <at> debbugs.gnu.org; Sat, 07 Feb 2026 19:20:32 -0500 Received: from fhigh-b6-smtp.messagingengine.com ([202.12.124.157]:38185) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1vosXL-0003BS-Nl for 80286 <at> debbugs.gnu.org; Sat, 07 Feb 2026 19:20:30 -0500 Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfhigh.stl.internal (Postfix) with ESMTP id B819B7A0089; Sat, 7 Feb 2026 19:20:21 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Sat, 07 Feb 2026 19:20:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1770510021; x=1770596421; bh=QomdK8/3S8SG2m+XH6YPKkUzXbO5KyMd2oHRKCmRlaM=; b= N0PUA4gXQLsIRmBWALPFBTHhNOvrm6PAbwUYdu5Nkqco8IC+tJ5GVM5e2svAcMCU 1DKPCp+EMz7SPXq8MbJB5jmPb+ICxODovJAsPZc6H63OMfBL6IXeNkeu3EPX563Q 3mfToDfQ1VVE7vr0aUcaWezN9730Q7ogHlVX5iipEFAh8BjsWdhEwrGDTbA2lnoy kSx4jqTc6e7Rg5JU97038yg5ImwU2uA3Gp7kk9BLA8xYhB7kLZFoEMM8+lFXMsAC W3evCGDk8ewHJB4tCIEIkoJSYFzz76lIOc7TRoMcTkWvYV47qRW4AZVCtq7Nnf/v H1yxlpDblDxNOx4R0FnRGQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1770510021; x= 1770596421; bh=QomdK8/3S8SG2m+XH6YPKkUzXbO5KyMd2oHRKCmRlaM=; b=k 8sxq7HiMr/GjOrCviWrBDBPXnkJ4tF21dpCKQ4q8S3CVa6px6di1AQtygDhD6G3D g6ZXvXvwziLlEZ4Cg7lmzMH+9PboGuuxtd9EAAXEVXENA9YbOgwhuOkRNd6GYDRz 4ccdG949n2+7E0n67YUD8ZFru9LLvGrggcejWcNXre+B2zLYo106fXL3lwzBBf4N PARGtQ0JnPZKUqbTK+ZPJa/+yGJp2rw0yQeoKTXJrITQ7EJOWUaF8TDiLIIT9umS WU8N3MdrgWOXgr20DFgVsyPhz4YlU4tubqd+8lPMxOpTCbMqHYN6YZoNZQ7q+QQc eGzX2zrCckqiYietWBneA== X-ME-Sender: <xms:xdaHaSW6-1mKs-9Wi7Bcf5H6cROycgIT7aCusN8MV-ozJahbPePpZg> <xme:xdaHaYC1yNbbIbBeQF08mAcx54b1GGI59K2B0BLq8AxiRc9l2nQYO6l4O66ZVWLVv JVHSyAo-IX7e-Mt8msEXfeYv2vyujQGoWf6KL9AfZoKY9i3ZHxD_Q> X-ME-Received: <xmr:xdaHaV-VHGejgaVcJ-ZSljEJz0pd8yF7MGJsO2pfhYDSfGIUOUTukmcR_FbJbc0Znqlw> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdduledvgeejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhithhr hicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvg hrnhepgeffhfevieevvdetjeejlefhvdfftdffgfehtdfgvdekteejvefgjeeivdekvdff necuffhomhgrihhnpehruhgshidqlhgrnhhgrdhorhhgpdguvggvphifihhkihdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhi thhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohepgedpmhhouggvpehsmhhtph houhhtpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohepmhhonhhn ihgvrhesihhrohdruhhmohhnthhrvggrlhdrtggrpdhrtghpthhtohepkedtvdekieesug gvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopehjohhhnhifsehgnhhurdhorhhg X-ME-Proxy: <xmx:xdaHafEG3jJVo3TotG_QAotNNf8E_dEdJpDi3Wgt23oritFmuHl0ZA> <xmx:xdaHaTNhHqK-oTrpV9KWEQnFXjnHiEgJzNp351xdlEXDCuEM0if9bQ> <xmx:xdaHaZfHWcqle3F-CHFvSAERu3ecmyvlwKtG2ovWu6XJNHlHOcaGNg> <xmx:xdaHaYvPYEic58_yYqO-RnnleS5X4gbpBKfKkbDJZQuZbMHrU5LWRw> <xmx:xdaHaZ7RKe-wpMjJa4Lvd_ueZVPc0_kxnt_6XN-5ZAk9pY4fhtQUybsW> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 7 Feb 2026 19:20:19 -0500 (EST) Message-ID: <0ba4200b-d166-4cb1-aece-605f88522649@HIDDEN> Date: Sun, 8 Feb 2026 02:20:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers To: Eli Zaretskii <eliz@HIDDEN> References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <c717c2e5-f0bf-47c0-b9b6-a8bd5dfe6203@HIDDEN> <jwvldh9u7n1.fsf-monnier+emacs@HIDDEN> <93e69553-aad9-4ff4-9190-cd3671b1897b@HIDDEN> <jwvh5rwbi1d.fsf-monnier+emacs@HIDDEN> <1904dc62-6bcc-4ef7-b586-6ebc0cf37d71@HIDDEN> <86ms1mw9s0.fsf@HIDDEN> <78937e00-d99f-4a65-9b20-e96242fc4c60@HIDDEN> <864intvse8.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <864intvse8.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, monnier@HIDDEN, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On 07/02/2026 11:01, Eli Zaretskii wrote: >> IIUC the idea is just to be able to wake the waiting thread without >> having to allocate another thread to run the timer or sentinel, by >> annotating the said timer or sentinel, with knowledge that they should >> wake a specific thread. > > How will this work? We can only "wake" a thread if we stop another > one, and do that in a way that is safe wrt the state of the Lisp > machine. The call to thread_select does that, but it is written on > the assumption that it's called by the thread which will be stopped, > not by some other thread. > >> Or IOW the goal would be to be able to use condition vars with just a >> single Lisp thread. > > What could be the use of a condvar when there's just one thread? The > only use I can see is that the condition-wait exists immediately, > perhaps with some error indication. To do that, we don't need any > complications like an additional C thread. (To comment on both paragraphs.) I don't know. Maybe the main thread should never run alone. Or maybe the "waker" code should have its own rhythms (probably running on a separate native thread) and itself do scheduling of Lisp threads to handle pending process output, timers, etc, see below (that would be a big change, though). >> It's a different semantics that has been useful enough in practice. And >> I remembered this difference because at some point I did reach for >> 'thread-resume', expecting a closer match in models. > > IME, thread-resume only makes sense if we also have thread-suspend to > match. Yes, like mentioned Fiber#yield does what you likely imagine thread-suspend would do (https://docs.ruby-lang.org/en/master/Fiber.html#method-c-yield). >> Speaking of that other model, it would be a regular thing to spin a >> "reactor" handling asynchronous events, which would delegate tasks to >> green threads from a pool (or just spawning them, up until some limit). >> So the idea to spawn a new thread (or get one from a pool) to handle a >> timer, like Stefan suggested near the beginning of this thread, does >> have a precedent. > > AFAIU, you are talking here about a very different threading model, > one where there are multiple threads running concurrently. Not in parallel, so similar to ours (with a global interpreter lock). > Or maybe I > don't understand what you are saying, because it is not concrete > enough. E.g., what is a thread handling asynchronous events, what > will it look like, and which events will each such thread handle? IIUC the key thing is that there is a "dispatcher" thread which monitors file handlers, and the pending timers, etc, and as soon as something is ready for reading, it wakes either the corresponding thread which was waiting for that bit of information, or maybe "some" thread in the case of timers, and moves on to the next pending event. > And > will they make sure no two threads try to handle the same event, given > our current way of waiting for events on the low level, which is > pselect? IIUC at the base it is an evented system which is based on tasks and registered callbacks. When an event arrives, there must be a saved reference to the callback which has to be run. Depending on the exact system I suppose the callback could be a function in high level code (Ruby/Lisp/JS), or it could just be a bit of information about which thread to wake. The programs I'm talking about are not text editors so there's bound to be some mismatch, but the pattern I'm referring to is called Reactor. Here's a small quote from an article: If you have ever used Node.js, you are familiar with the concept of an event loop. The Reactor is essentially a continuous loop that monitors various I/O sources—like network sockets or file descriptors—to see if they are ready for reading or writing. Instead of a thread sitting idle and "blocking" while waiting for a database to respond, the Reactor puts that specific task to sleep and moves on to the next task in the queue. When the database finally responds, the Reactor receives a notification from the operating system, finds the task that was waiting for that data, and resumes it exactly where it left off. Because this happens inside a single thread [...elided...], the overhead is incredibly low. The async gem provides a clean Ruby implementation of this Reactor, allowing you to manage thousands of concurrent connections without the memory bloat of thousands of OS threads. This was about the latest implementation of that pattern. 10-15 years ago there was another popular library called EventMachine. Here is a description of it, with diagrams: https://deepwiki.com/eventmachine/eventmachine This one just has an event reactor but no direct support for green threads (fibers). The latter plug in by a separate library on top of the reactor, roughly like this: when a fiber needs to do a blocking operation, it sets up a callback for that operation's completion (and maybe callbacks for streaming, e.g. for a network response), and then yields execution. When corresponding events arrive, the reactor looks up which callbacks are registered with them, executes the callbacks (in application code, this would be Lisp code in our case), and among them the callback which wakes the fiber, allowing it to process the newly arrived data. I can't comment on the specifics of using 'pselect', but according to the diagrams behind the link above, EventMachine can interface with epoll, kqueue and select. Some relevant places in its implementation are linked as well.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 7 Feb 2026 09:02:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 07 04:02:06 2026 Received: from localhost ([127.0.0.1]:33091 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1voeCb-0003y6-TJ for submit <at> debbugs.gnu.org; Sat, 07 Feb 2026 04:02:06 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46612) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1voeCW-0003xM-IG for 80286 <at> debbugs.gnu.org; Sat, 07 Feb 2026 04:02:04 -0500 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 <eliz@HIDDEN>) id 1voeCR-0003c9-7M; Sat, 07 Feb 2026 04:01:55 -0500 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=mZ6dDfKg9WyV8E3+PphBVnZydZuf60FTBp0XROKtVsM=; b=LR0BuinRG8hE 4XQM0/CuXzCvzeqCkdcO9NYHPGfydBm0Rk1umfdyx8LyXtkDWHIuNKeJEgOPYt9LcugT88JRXbYOR wYJ29iT8YKoSTYgUnw69oNMWhdvYOwR3q6i90E9b37ao8HU8YU7hRrRbdQWyaaGqjtO8F5iuJosRL SPdhgpevCyxZ9PebyjhHcG/qFZXEk4I5k+M3mOi+mVTVg58j/l7CI0zROFisCwU/D6d+K6NbT5H97 tqUaq9IuEQGjMUPcyE+n51qdrCdrtDvDHqNQu0r1F+5PTBrYkGNODUidxvskz2Dt8ubcKGj7UQ0VN jXmw+R0scNOsJwgetrzJ+A==; Date: Sat, 07 Feb 2026 11:01:51 +0200 Message-Id: <864intvse8.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <78937e00-d99f-4a65-9b20-e96242fc4c60@HIDDEN> (message from Dmitry Gutov on Sat, 7 Feb 2026 02:47:27 +0200) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <c717c2e5-f0bf-47c0-b9b6-a8bd5dfe6203@HIDDEN> <jwvldh9u7n1.fsf-monnier+emacs@HIDDEN> <93e69553-aad9-4ff4-9190-cd3671b1897b@HIDDEN> <jwvh5rwbi1d.fsf-monnier+emacs@HIDDEN> <1904dc62-6bcc-4ef7-b586-6ebc0cf37d71@HIDDEN> <86ms1mw9s0.fsf@HIDDEN> <78937e00-d99f-4a65-9b20-e96242fc4c60@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, monnier@HIDDEN, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sat, 7 Feb 2026 02:47:27 +0200 > Cc: monnier@HIDDEN, 80286 <at> debbugs.gnu.org, johnw@HIDDEN > From: Dmitry Gutov <dmitry@HIDDEN> > > On 06/02/2026 10:34, Eli Zaretskii wrote: > > > Personally, I don't understand how an internal C thread that is not > > synchronized with the global lock, could schedule timers. Timers > > generally run Lisp code, so this would mean we allow two separate > > threads to run Lisp simultaneously, which will never work well. Or > > what am I missing? > > IIUC the idea is just to be able to wake the waiting thread without > having to allocate another thread to run the timer or sentinel, by > annotating the said timer or sentinel, with knowledge that they should > wake a specific thread. How will this work? We can only "wake" a thread if we stop another one, and do that in a way that is safe wrt the state of the Lisp machine. The call to thread_select does that, but it is written on the assumption that it's called by the thread which will be stopped, not by some other thread. > Or IOW the goal would be to be able to use condition vars with just a > single Lisp thread. What could be the use of a condvar when there's just one thread? The only use I can see is that the condition-wait exists immediately, perhaps with some error indication. To do that, we don't need any complications like an additional C thread. > >> That reminds me that our threads' implementation doesn't have anything > >> like 'thread-resume'. But when it calls 'thread-yield', remains for > >> automatic rescheduling later. > > > > If by thread-resume you mean a means to give a specific thread the > > global lock it's waiting for, we'd first need some means of finding > > out that a thread waits for the global lock. > > Then the harder part is> somehow to tell the scheduler to waken only > that thread, if several > > threads are waiting for the global lock. > > I'd also like to hear about specific use cases where this could be> > useful. > > It's a different semantics that has been useful enough in practice. And > I remembered this difference because at some point I did reach for > 'thread-resume', expecting a closer match in models. IME, thread-resume only makes sense if we also have thread-suspend to match. > An advantage is that the thread being suspended-resumed could after that > point be confident that whatever body of work it yielded to, is now > done. Or that you could have a "pool" of green threads just waiting, > without any automatic attempts to schedule them (probably easier to have > more threads this way). But as you say below... > > >> In another green threads impl I'm familiar with (Ruby Fibers), a fiber > >> can #yield and will wait until its #resume method is called - often by > >> an entity similar to our timers or process sentinels. But that requires, > >> of course, at least one other fiber to be running, to make that call. > > > > This could be emulated by a mutex or a condvar, no? > > ...it can be emulated, I guess. Just more boilerplate. > > Speaking of that other model, it would be a regular thing to spin a > "reactor" handling asynchronous events, which would delegate tasks to > green threads from a pool (or just spawning them, up until some limit). > So the idea to spawn a new thread (or get one from a pool) to handle a > timer, like Stefan suggested near the beginning of this thread, does > have a precedent. AFAIU, you are talking here about a very different threading model, one where there are multiple threads running concurrently. Or maybe I don't understand what you are saying, because it is not concrete enough. E.g., what is a thread handling asynchronous events, what will it look like, and which events will each such thread handle? And will they make sure no two threads try to handle the same event, given our current way of waiting for events on the low level, which is pselect?
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 7 Feb 2026 00:47:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 06 19:47:40 2026 Received: from localhost ([127.0.0.1]:58295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1voWU7-0000zi-Hk for submit <at> debbugs.gnu.org; Fri, 06 Feb 2026 19:47:40 -0500 Received: from fhigh-a5-smtp.messagingengine.com ([103.168.172.156]:49037) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1voWU4-0000zS-Oe for 80286 <at> debbugs.gnu.org; Fri, 06 Feb 2026 19:47:37 -0500 Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfhigh.phl.internal (Postfix) with ESMTP id 88BF21400105; Fri, 6 Feb 2026 19:47:31 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Fri, 06 Feb 2026 19:47:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1770425251; x=1770511651; bh=So0R9IHWsUJz9ZOTqwNvt56lO5V+PtqSaBOMmF5EyQs=; b= c7GQuIDQ4JZgUwc6ZHs+FYvq8LizNv4zHjdfcJwNab1Gi/mQiqtwsyX/9VN484sB ZSV/W6klCcgKwXtukQ9XqFl79guE3PEXspAIQhsOqJy0HyoXRXWsVzjOpEZyOrCL Vze+8xLPL3z1u4t9uYk5ojMk7OiOqXoGqXpTVu3sq4N2k1qayP5AYRfRPptGE6jD hdjTn+PGLI2AqdMMtOwpU5MPvXZXNIjYN09KegCuQ7y0apw1cPa+I97OOCQcV20G 6dvwXk7c3Xp3UQiWat+Sj4hCa6Zxv3Rbxec8q/snc2mEeVeihRaatFlxDmMDAr2Z pJxO2tkftWT6CyDeEbA5Hg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1770425251; x= 1770511651; bh=So0R9IHWsUJz9ZOTqwNvt56lO5V+PtqSaBOMmF5EyQs=; b=n GEQ/FP9nF8N/yVNAbeTpr4vBArApcolMN7dItZjKl3EnM1Zt0TEvYC8EpL3X9SYL QYs2g4PvqtUrlRMeG8tQJRXp+aZWdOX5SoZA2Jy9p2ZWsJtZdy1IYbm7Ns1hK2r/ AnVcr4/iW5u3GeMnBP9DwYHPO+LTCXl0ZSj8vjXZiRCIezUD60aVrCoE/6TvhS+5 6j9nQgNzD4wiupRTkLjkLQCK2d52Bo19zft9a9NbmH/jJcH7fz5QQNlGBWeSKmYQ 4a1hru4hVc4o8Vr2pC52ysyj789aQ04Tt4wpTSJiHeP9rxpidQ0EJS/7fjTzRsgG SgFp1ZVI/bmRdylj4sjSA== X-ME-Sender: <xms:o4uGaR_d1Gananx-N4Ty84Bjc0KZrDBLVfXm6ImHniWo-sI_RF9KKg> <xme:o4uGaTgOAJuuYdrwIcWbXOiEh-RgK5pIBsFeq39x-PrrgC68uRPZjeyx3MShMYkp2 w_4L3Q2aM-EfV3NHbVj-E3ke5QYL6sxyIc9rKkrLfIlep-yioi3Bu4> X-ME-Received: <xmr:o4uGaZeTrWSe81jd4_ixxyY8mUf9edMkbqhL292x8yQ5qzuxIx9iNbCnL2-9zP1f1Gkp> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddukeelieegucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhr hicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvg hrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedujeeh necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmih htrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhp ohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehmohhnnh hivghrsehirhhordhumhhonhhtrhgvrghlrdgtrgdprhgtphhtthhopeektddvkeeisegu vggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepjhhohhhnfiesghhnuhdrohhrgh X-ME-Proxy: <xmx:o4uGaSrPSyCHXTGItY6TvPwSBcodOUco5cGt6PCTtNsa8JYM_Xf6Zw> <xmx:o4uGaWAECstPV4lHMowvw335dm1RPdWbz7pUMUcU9f8qN7jCqDG4sg> <xmx:o4uGaXYD39Y4Xb430OVH0H6-qTupqDHO_VxiAlREPhxH1eUDpfyChA> <xmx:o4uGaR4Q6wEnfz_vxLk_oEPS6Y9Ay_5kMlOnQPCGAXziM2fUoFK_Cw> <xmx:o4uGaak1Git9dUELy1FPpW3LK72oeHo77OLy74IwJJXVGl_PCGmMfLoH> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 6 Feb 2026 19:47:29 -0500 (EST) Message-ID: <78937e00-d99f-4a65-9b20-e96242fc4c60@HIDDEN> Date: Sat, 7 Feb 2026 02:47:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers To: Eli Zaretskii <eliz@HIDDEN> References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <c717c2e5-f0bf-47c0-b9b6-a8bd5dfe6203@HIDDEN> <jwvldh9u7n1.fsf-monnier+emacs@HIDDEN> <93e69553-aad9-4ff4-9190-cd3671b1897b@HIDDEN> <jwvh5rwbi1d.fsf-monnier+emacs@HIDDEN> <1904dc62-6bcc-4ef7-b586-6ebc0cf37d71@HIDDEN> <86ms1mw9s0.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <86ms1mw9s0.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, monnier@HIDDEN, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On 06/02/2026 10:34, Eli Zaretskii wrote: > Personally, I don't understand how an internal C thread that is not > synchronized with the global lock, could schedule timers. Timers > generally run Lisp code, so this would mean we allow two separate > threads to run Lisp simultaneously, which will never work well. Or > what am I missing? IIUC the idea is just to be able to wake the waiting thread without having to allocate another thread to run the timer or sentinel, by annotating the said timer or sentinel, with knowledge that they should wake a specific thread. Or IOW the goal would be to be able to use condition vars with just a single Lisp thread. >> That reminds me that our threads' implementation doesn't have anything >> like 'thread-resume'. But when it calls 'thread-yield', remains for >> automatic rescheduling later. > > If by thread-resume you mean a means to give a specific thread the > global lock it's waiting for, we'd first need some means of finding > out that a thread waits for the global lock. > Then the harder part is> somehow to tell the scheduler to waken only that thread, if several > threads are waiting for the global lock. > I'd also like to hear about specific use cases where this could be> useful. It's a different semantics that has been useful enough in practice. And I remembered this difference because at some point I did reach for 'thread-resume', expecting a closer match in models. An advantage is that the thread being suspended-resumed could after that point be confident that whatever body of work it yielded to, is now done. Or that you could have a "pool" of green threads just waiting, without any automatic attempts to schedule them (probably easier to have more threads this way). But as you say below... >> In another green threads impl I'm familiar with (Ruby Fibers), a fiber >> can #yield and will wait until its #resume method is called - often by >> an entity similar to our timers or process sentinels. But that requires, >> of course, at least one other fiber to be running, to make that call. > > This could be emulated by a mutex or a condvar, no? ...it can be emulated, I guess. Just more boilerplate. Speaking of that other model, it would be a regular thing to spin a "reactor" handling asynchronous events, which would delegate tasks to green threads from a pool (or just spawning them, up until some limit). So the idea to spawn a new thread (or get one from a pool) to handle a timer, like Stefan suggested near the beginning of this thread, does have a precedent.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 6 Feb 2026 08:34:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 06 03:34:18 2026 Received: from localhost ([127.0.0.1]:50561 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1voHIA-0007hx-EF for submit <at> debbugs.gnu.org; Fri, 06 Feb 2026 03:34:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51022) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1voHI8-0007hh-20 for 80286 <at> debbugs.gnu.org; Fri, 06 Feb 2026 03:34:16 -0500 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 <eliz@HIDDEN>) id 1voHI2-0002g1-1B; Fri, 06 Feb 2026 03:34:10 -0500 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=9PlJ7i/ImJY9c80clcGQnsPawOu0BHjfFmuzXQiNRtE=; b=a8qpzMMKe54k HAsPK8w+sbRoXY+geba7y+ds5ebSGsTlWoCJkxRgFBeJS+DKO5XE9ZxTR56tLxw6Vh/OX/wYSw1wQ Tg+mxDSNS1y+rT0ppMwYoDrSorFQ2FbJnqadfp08LkPc+sSZflHQYeagTCUxc94E575WZ/9G4u2D+ yLU2ysvDjsyEz3EUJGp5OV6IDkoisxogDrv/jz8moVzya69pXF1QiZ8sDSmfXXqYdyVBpE0XTNBgf inRqUcR814j18tM+CB5TwlrnHJAeHbb9AJl1BsEEAFj1G0To7f9jSvzkn8XqUnIcbGKEPTAJ29CE4 gd5Wbpdmy+qRTYmASnKBYw==; Date: Fri, 06 Feb 2026 10:34:07 +0200 Message-Id: <86ms1mw9s0.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <1904dc62-6bcc-4ef7-b586-6ebc0cf37d71@HIDDEN> (message from Dmitry Gutov on Fri, 6 Feb 2026 06:30:09 +0200) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <c717c2e5-f0bf-47c0-b9b6-a8bd5dfe6203@HIDDEN> <jwvldh9u7n1.fsf-monnier+emacs@HIDDEN> <93e69553-aad9-4ff4-9190-cd3671b1897b@HIDDEN> <jwvh5rwbi1d.fsf-monnier+emacs@HIDDEN> <1904dc62-6bcc-4ef7-b586-6ebc0cf37d71@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, monnier@HIDDEN, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Fri, 6 Feb 2026 06:30:09 +0200 > Cc: Eli Zaretskii <eliz@HIDDEN>, 80286 <at> debbugs.gnu.org, johnw@HIDDEN > From: Dmitry Gutov <dmitry@HIDDEN> > > >>> It wouldn't run any of the associated ELisp code but would just propagate > >>> the notification the ELisp threads. > >>> The idea would be that we could then extend timers and sentinels with > >>> the functionality of doing a `condition-notify` instead of running > >>> code, in which case that internal C thread could directly perform the > >>> `condition-notify` without having to wait for an ELisp thread to be > >>> ready to run ELisp code. > >>> [ Not sure it would provide the functionality my library needs, tho. ] > >> > >> It sound interesting in a way that it could increase parallelism by being > >> able to avoid running Lisp code in more cases. Not sure how I feel about > >> that - running Lisp is generally a good idea to me. > > > > I wasn't thinking it in terms of running less ELisp code, but in being > > able to wake up a thread without having to have an ELisp thread looping > > in `a-p-o`. It makes those events much more like interrupts in that > > they would happen regardless of the state of any ELisp threads. > > It basically just separates the task of scheduling execution of > > a timer/sentinel/... from the task of actually running the > > associated code. Personally, I don't understand how an internal C thread that is not synchronized with the global lock, could schedule timers. Timers generally run Lisp code, so this would mean we allow two separate threads to run Lisp simultaneously, which will never work well. Or what am I missing? > That reminds me that our threads' implementation doesn't have anything > like 'thread-resume'. But when it calls 'thread-yield', remains for > automatic rescheduling later. If by thread-resume you mean a means to give a specific thread the global lock it's waiting for, we'd first need some means of finding out that a thread waits for the global lock. Then the harder part is somehow to tell the scheduler to waken only that thread, if several threads are waiting for the global lock. If what you mean is to give the lock to _any_ thread, then we already have that: thread-yield or sleep-for or sit-for or other similar calls. I'd also like to hear about specific use cases where this could be useful. > In another green threads impl I'm familiar with (Ruby Fibers), a fiber > can #yield and will wait until its #resume method is called - often by > an entity similar to our timers or process sentinels. But that requires, > of course, at least one other fiber to be running, to make that call. This could be emulated by a mutex or a condvar, no?
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 6 Feb 2026 04:30:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 05 23:30:22 2026 Received: from localhost ([127.0.0.1]:49021 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1voDU6-0008LT-6g for submit <at> debbugs.gnu.org; Thu, 05 Feb 2026 23:30:22 -0500 Received: from fhigh-a1-smtp.messagingengine.com ([103.168.172.152]:39601) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1voDU2-0008Ky-Ps for 80286 <at> debbugs.gnu.org; Thu, 05 Feb 2026 23:30:19 -0500 Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfhigh.phl.internal (Postfix) with ESMTP id 89948140015A; Thu, 5 Feb 2026 23:30:13 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-12.internal (MEProxy); Thu, 05 Feb 2026 23:30:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1770352213; x=1770438613; bh=uvANgnAXZUKE/Uq+WSAIp/5GSmSD9Fa358f8s2JBDUo=; b= dIsTDFXb4+bUoAz3/hcOwCuVUBXtkJNlANrwLYdrdDHCDaEBD9UGhUTmHsusJRgQ E2qVJ1GESqR0ZPzC/usF+WKXV2XxOH6e3UH2w/49l1Z2EHvnqbhQCaybGQcNEh77 59GJLYgEj64KmfvfCoumO3AD7VR4EKz878qttAYvAYhFkjv0mCbEIjkinj9ST70G r8RhPIPGaQJNk8G5KL+dNXE+9RrvFsaV5EfVA7WW+K4HroWhRe7fo4A0PMsVo0cy +EKWqg0SsjJQP+wPgcN6MGnDTZsjc6uy3CEDEQTJ1RJEw82z0TnowerbBsI+Ivhu lGHvC7kAd8nNJM/Uau2vCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1770352213; x= 1770438613; bh=uvANgnAXZUKE/Uq+WSAIp/5GSmSD9Fa358f8s2JBDUo=; b=O OTnSY4DWDzbCcku76O8wgDkuH82vWwyurS4mMhcBwQQwf3kDZahEuCLts5Gg9EYE /Gu+h7183Rsb5sytlFout2pxPO/DtkybkQpbK0zRBH31iwzqkLXgC0F3ABmX7xyl vcOw/msK/ua/Ok51g5BZr7n9ZWdoKRK3Q9tgkK584TG3UnSynxfwR9oPhr9DKfGu y0eRHs2B09H69r9FXTBUlFsz5kWM+fL7A1W/APd6qJHpBBozb1o6lXJZ/Wqw9CuX PB9WozAAvvJx9csg4oNmQbsPpWhIKmFfZdsEfMGzuYQ+ZYMrSOfWi5iAF+L0D9GS gbEOs5CFuul+NPtnIhvSw== X-ME-Sender: <xms:VW6FaaS9C1G8-_RTa1BEmBxJuFxjAMK0haF_Uh2bygKp9G7Q1sspoQ> <xme:VW6FadkksfIeXwoPfpCp6mhJbDeMDXhqE0hc8VVwYWbAKER6RwtJiQ8hJBKMzE5jR owvUMaXCbGNjIvH3qb8rwVmCJAcziFAUlWK7JAbxucp55wnM3W1HA> X-ME-Received: <xmr:VW6FaSTc1E8JZGSbxPC2n7BpeGWlIUSbXXu1004QpZQa0XwgV3B92xabp1J62122xWsp> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddukeejvdduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhr hicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvg hrnhepffeifedvleeukedtgfelieegudfgveekfeejveejffetffeuueeugefhveeiuddv necuffhomhgrihhnpehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgt phhtthhopeegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehmohhnnhhivghrse hirhhordhumhhonhhtrhgvrghlrdgtrgdprhgtphhtthhopegvlhhiiiesghhnuhdrohhr ghdprhgtphhtthhopeektddvkeeiseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpth htohepjhhohhhnfiesghhnuhdrohhrgh X-ME-Proxy: <xmx:VW6FaTNhMLMeJiTX81XZFyCIX1YEhAGYMe4-M3ZXrhWiwFaTAapiCw> <xmx:VW6FaTVI3B-9uJ5Lf20C2wct_v9Q4iLJ8LSRLxsWN64PBXmqQjhppQ> <xmx:VW6FaSdDsxvTF_rlNgMDpcPZJ9TXfe8Y463VaZz_GQ09n6M9q8ZxFQ> <xmx:VW6FaXs0rzYAANHCXO1JwvHSGn7fg1LqVBihZ8MsmIt_Rem2xkWOUA> <xmx:VW6FaejQXcGiXVPZDzXJo4RVV5DxFiZdcV2MhEQ9AA2VCbs005syU1PQ> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 5 Feb 2026 23:30:11 -0500 (EST) Message-ID: <1904dc62-6bcc-4ef7-b586-6ebc0cf37d71@HIDDEN> Date: Fri, 6 Feb 2026 06:30:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers To: Stefan Monnier <monnier@HIDDEN> References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <c717c2e5-f0bf-47c0-b9b6-a8bd5dfe6203@HIDDEN> <jwvldh9u7n1.fsf-monnier+emacs@HIDDEN> <93e69553-aad9-4ff4-9190-cd3671b1897b@HIDDEN> <jwvh5rwbi1d.fsf-monnier+emacs@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <jwvh5rwbi1d.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80286 Cc: Eli Zaretskii <eliz@HIDDEN>, 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On 04/02/2026 18:33, Stefan Monnier wrote: > `thread-join` ... doesn't propagate the error > when the thread ends with an error. Mistakenly, I'm sure. >>> It wouldn't run any of the associated ELisp code but would just propagate >>> the notification the ELisp threads. >>> The idea would be that we could then extend timers and sentinels with >>> the functionality of doing a `condition-notify` instead of running >>> code, in which case that internal C thread could directly perform the >>> `condition-notify` without having to wait for an ELisp thread to be >>> ready to run ELisp code. >>> [ Not sure it would provide the functionality my library needs, tho. ] >> >> It sound interesting in a way that it could increase parallelism by being >> able to avoid running Lisp code in more cases. Not sure how I feel about >> that - running Lisp is generally a good idea to me. > > I wasn't thinking it in terms of running less ELisp code, but in being > able to wake up a thread without having to have an ELisp thread looping > in `a-p-o`. It makes those events much more like interrupts in that > they would happen regardless of the state of any ELisp threads. > It basically just separates the task of scheduling execution of > a timer/sentinel/... from the task of actually running the > associated code. That reminds me that our threads' implementation doesn't have anything like 'thread-resume'. But when it calls 'thread-yield', remains for automatic rescheduling later. In another green threads impl I'm familiar with (Ruby Fibers), a fiber can #yield and will wait until its #resume method is called - often by an entity similar to our timers or process sentinels. But that requires, of course, at least one other fiber to be running, to make that call. >> IIRC Spencer was describing a somewhat related scheme involving threads, >> process sentinels and condition variables (with threads being spawned >> together with processes). I can't find a full description right now, but >> this might be relevant: >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79333#14, in case you missed >> this thread. > > [ Thanks for the link, I can't remember having seen it back then. ] > > Indeed, that's very related. My idea would also provide a new solution > to the problem of locking processes to threads: by separating the > scheduling of the code from the actual execution, Sounds good. It could just be a shame if the shape of that function will be too close to one of the existing ones (implying that that one could have been "fixed" instead). > it lets (well, forces) > the programmer to choose in which thread the sentinel/filter code is > run, so we could eventually get rid of this notion of a process > being (or not) tied to a specific thread. Meaning they could (and be encouraged to) choose a different thread? >>> - Add a new function that combines `condition-wait` with >>> `accept-process-output`. >> An accept-process-output loop that returns as soon as a condition variable >> is notified? Makes sense. >> If we had a-p-o were improved to return fast reliably, though, I would >> probably start with implementing a poor version of this with an a-p-o loop >> and a plain Lisp variable. > > Sorry, I don't understand what you mean by such a loop. a-p-o running in a loop waiting together with some scheme that would allow a timer to interrupt it. Or a process sentinel running within the bounds of that loop could signal some error, to have it interrupted.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 4 Feb 2026 17:52:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 04 12:52:46 2026 Received: from localhost ([127.0.0.1]:34470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vnh3V-0000hs-Rs for submit <at> debbugs.gnu.org; Wed, 04 Feb 2026 12:52:46 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:44091) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1vnh3S-0000hT-W6 for 80286 <at> debbugs.gnu.org; Wed, 04 Feb 2026 12:52:43 -0500 From: Spencer Baugh <sbaugh@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers In-Reply-To: <jwvh5rwbi1d.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message of "Wed, 04 Feb 2026 11:33:06 -0500") References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <c717c2e5-f0bf-47c0-b9b6-a8bd5dfe6203@HIDDEN> <jwvldh9u7n1.fsf-monnier+emacs@HIDDEN> <93e69553-aad9-4ff4-9190-cd3671b1897b@HIDDEN> <jwvh5rwbi1d.fsf-monnier+emacs@HIDDEN> Date: Wed, 04 Feb 2026 17:52:36 +0000 Message-ID: <ierjyws1jmj.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1770227557; bh=lbpxJ/MTaIOrPq+9GmaBe6LZmZpu8zYTrfcR7Mx/Je8=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=mlgp5X7ZGRMkBom7wq0pBiz/Rm8iZZ5f/9MJV4FfGZOYeBsEksEO259qqbUMFhLdD daMkFKFApD4BWnT10CHSPFoQetHWw/EqjzmRbXyRBY4Z4FkQevlYQimSYsMDEJTLmn JshXc+kXfQjUrRs2cJKq6hq2AScmI6J5WBnrHWHCOf+f2foD+42ZZ6NxJmR3uiLshL /Pk372AqxskRyFW6MouHCN9cITOhKe+tPbnYjY52Opu5Wwr2RcWEx2xeQnRYH+V0Bn g9lv/b+tLl2oGJoz8zRNqHKqTF4j52eGUOUWA1oPQOQccOZOqbW99q7vRteWQB0+PW WJYE5mcewkjeA== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: Dmitry Gutov <dmitry@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Stefan Monnier <monnier@HIDDEN> writes: >> IIRC Spencer was describing a somewhat related scheme involving threads, >> process sentinels and condition variables (with threads being spawned >> together with processes). I can't find a full description right now, but >> this might be relevant: >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79333#14, in case you missed >> this thread. > > [ Thanks for the link, I can't remember having seen it back then. ] > > Indeed, that's very related. My idea would also provide a new solution > to the problem of locking processes to threads: by separating the > scheduling of the code from the actual execution, it lets (well, forces) > the programmer to choose in which thread the sentinel/filter code is > run, so we could eventually get rid of this notion of a process > being (or not) tied to a specific thread. This is a very long thread and I haven't read most of it. I agree that this is a severe bug. It's one of the reasons why Elisp threads are currently completely unusable for real world programs or libraries. The correct fix here is to rewrite the "condition variable" implementation to use file descriptors for notification instead of pthread condvars. Then we can incorporate condition variables into the wait_reading_process_output event loop, such that we could simultaneously wait on a condition variable while running timers and process filters. This is not that hard and someone should just do it.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 4 Feb 2026 16:33:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 04 11:33:17 2026 Received: from localhost ([127.0.0.1]:33928 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vnfoa-0005N9-Oa for submit <at> debbugs.gnu.org; Wed, 04 Feb 2026 11:33:17 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:22991) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vnfoY-0005Mt-3y for 80286 <at> debbugs.gnu.org; Wed, 04 Feb 2026 11:33:15 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 089DC81C62; Wed, 4 Feb 2026 11:33:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1770222786; bh=Lf6do12rvi0OxVkHeO+WW5ziJK69DFTVBr+NDv+HNDE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=CFynrvEn/J7kGTpVspJK2TxkvXy2p0IKxwzOTh66e/2us2kdHbT0c98+RKt6+HKZU Kg4o8vZBg4zWI7YgM4vk6ATcpxyt8QEEF9OkePPHTNXifnQSntPK9blAU0bupKS5QU sVOgicKC5hFDY3lcLorrOlKDauGfNb3Dd2XVev+xDP+us+1IoJuFeB8YknUONvmuSc 5lLmPbcF3LwlVJbevR/2mo8ox0J6Sno2Cetff3BSheFwKb5aH5pijI2KQGxdT6CBgQ DXr/UrQYaK/KrUKquLIRntfiiLySUFY6rxBum/qgukZIphaMQjHXkBAHLXLXwzq9Ng jiL0JFDTDniOQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E014B8093E; Wed, 4 Feb 2026 11:33:06 -0500 (EST) Received: from asado (modemcable116.38-202-24.mc.videotron.ca [24.202.38.116]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B91C3120A73; Wed, 4 Feb 2026 11:33:06 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers In-Reply-To: <93e69553-aad9-4ff4-9190-cd3671b1897b@HIDDEN> Message-ID: <jwvh5rwbi1d.fsf-monnier+emacs@HIDDEN> References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <c717c2e5-f0bf-47c0-b9b6-a8bd5dfe6203@HIDDEN> <jwvldh9u7n1.fsf-monnier+emacs@HIDDEN> <93e69553-aad9-4ff4-9190-cd3671b1897b@HIDDEN> Date: Wed, 04 Feb 2026 11:33:06 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.074 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: Eli Zaretskii <eliz@HIDDEN>, 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) >> (I think this is >> inevitable: the thread level can't know where the error may need to be >> propagated. In general they may need to be propagated to several >> places). > > Certainly. But just to tie that in with the older discussion, though: > I think thread-join could be called from several places too, and could > signal error in all of them. Oh, indeed, `thread-join` smells strongly like `my futur-blocking-wait` and the only discrepancy is the fact that it doesn't propagate the error when the thread ends with an error. >> It wouldn't run any of the associated ELisp code but would just propagate >> the notification the ELisp threads. >> The idea would be that we could then extend timers and sentinels with >> the functionality of doing a `condition-notify` instead of running >> code, in which case that internal C thread could directly perform the >> `condition-notify` without having to wait for an ELisp thread to be >> ready to run ELisp code. >> [ Not sure it would provide the functionality my library needs, tho. ] > > It sound interesting in a way that it could increase parallelism by being > able to avoid running Lisp code in more cases. Not sure how I feel about > that - running Lisp is generally a good idea to me. I wasn't thinking it in terms of running less ELisp code, but in being able to wake up a thread without having to have an ELisp thread looping in `a-p-o`. It makes those events much more like interrupts in that they would happen regardless of the state of any ELisp threads. It basically just separates the task of scheduling execution of a timer/sentinel/... from the task of actually running the associated code. > IIRC Spencer was describing a somewhat related scheme involving threads, > process sentinels and condition variables (with threads being spawned > together with processes). I can't find a full description right now, but > this might be relevant: > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79333#14, in case you missed > this thread. [ Thanks for the link, I can't remember having seen it back then. ] Indeed, that's very related. My idea would also provide a new solution to the problem of locking processes to threads: by separating the scheduling of the code from the actual execution, it lets (well, forces) the programmer to choose in which thread the sentinel/filter code is run, so we could eventually get rid of this notion of a process being (or not) tied to a specific thread. >> - Add a new function that combines `condition-wait` with >> `accept-process-output`. > An accept-process-output loop that returns as soon as a condition variable > is notified? Makes sense. > If we had a-p-o were improved to return fast reliably, though, I would > probably start with implementing a poor version of this with an a-p-o loop > and a plain Lisp variable. Sorry, I don't understand what you mean by such a loop. === Stefan
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 4 Feb 2026 01:48:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 03 20:48:05 2026 Received: from localhost ([127.0.0.1]:53404 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vnRzx-0005U1-Bn for submit <at> debbugs.gnu.org; Tue, 03 Feb 2026 20:48:05 -0500 Received: from fout-a5-smtp.messagingengine.com ([103.168.172.148]:37319) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1vnRzu-0005TU-BR for 80286 <at> debbugs.gnu.org; Tue, 03 Feb 2026 20:48:02 -0500 Received: from phl-compute-08.internal (phl-compute-08.internal [10.202.2.48]) by mailfout.phl.internal (Postfix) with ESMTP id 233FFEC024F; Tue, 3 Feb 2026 20:47:57 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-08.internal (MEProxy); Tue, 03 Feb 2026 20:47:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1770169677; x=1770256077; bh=ijTFrqLcyR3D52wSJWDaQDsoGPxGS84BYEIXkQpHoPg=; b= muppXlM6KPpr3LApaGF4Gk+F4/OyIKSH9xjKTojk+NGhnsPydq0dI3T/LtRoEKMw ulZ8zsCLVVIiBuOTTfbWMoLZsyRB3ll85YAk6mH0CYq/+Kf1m5SjIZThGXqOEuU4 cTFpeN6IWfphfpwXYFY4wSXAlorkGw/0YLcvYkiIXXz+5LgtCflNmbMLjs+hVeOB /xYgKuf/wwQXGc5RNte1XObf89w4GiqsANSSgc7fMNixL/5ppibi12l0yDLzlm1s D1InD77Pl50D8x2MmPXRe8e42WV4Bhe4mclnMoTg4po/bkYscTZkAbL7HiKuDtSm +SkFTg6eGfY4DfuCxtUfNg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1770169677; x= 1770256077; bh=ijTFrqLcyR3D52wSJWDaQDsoGPxGS84BYEIXkQpHoPg=; b=F g4NAQj1VkT5hiuZD318ArsHSdvtDz+y1d2NeI097g1VGjcfzznSp9K5SXN5tsRAf H/YYZxuNsSWlKTfod0VrH3xqTZalV9yqw3ysWd1VRGVofLU4bdqx0XyKK5iDVkPu /w/5f0BADdZFgAZK0f5f0dtO5H0eqvw7JgpkqXY1YdX4ulDUdPNvSxL3eQm4WCGk e0hCkIY9I/+cujMYr6LrF0gyDX8NtlP5xN6cnb2FOaJNWaLkagyC1J17XdgnMn/a LwlZbR9slGB+iZgpJViYvkhqKR93vuD4G2e9ulQE1c1oEvxcyfsrD3vWyI3qGM6Y WVkF4kJ8OvE0w9r2vVa8Q== X-ME-Sender: <xms:TKWCafU-qdhKlqGXjmbV06W0vjwt-coU_5u-fDNBsM5yFYGx0DHzvQ> <xme:TKWCaVb6m6eju7ipPetXtfQmZefHOfXq8GJ6EY32SPVwKvREfTQFbPDkMFhJrpEhw 5QnRzV7Fx4oZBEYhXwITQQzJEFDVwQIqABqK4-1a9Kaqq9rfg0K4xE> X-ME-Received: <xmr:TKWCaV0Q3IjjQQReZmn9dHx5PU6p03rRjQM5i9W3OC0J3ANlK1qKm2DTFdzQLPc2GXVf> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddukeduieegucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhr hicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvg hrnhepffeifedvleeukedtgfelieegudfgveekfeejveejffetffeuueeugefhveeiuddv necuffhomhgrihhnpehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgt phhtthhopeegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehmohhnnhhivghrse hirhhordhumhhonhhtrhgvrghlrdgtrgdprhgtphhtthhopegvlhhiiiesghhnuhdrohhr ghdprhgtphhtthhopeektddvkeeiseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpth htohepjhhohhhnfiesghhnuhdrohhrgh X-ME-Proxy: <xmx:TKWCaXjTuAaafysKAUdBSMYlBnUKIkJAjllETK87EBlX90qDOUiOGA> <xmx:TKWCaZbtOnWEx7wTejXmGdLIki-9gGKaOyOT8KVQTlPIOtjgX27ypA> <xmx:TKWCaXTTABHiGsmf_Qa81H7CAht1E4pwZkBsYhL1cEXeqMZiCXm5mA> <xmx:TKWCaUTTViX3qsovsTziL8OtzN-0z9ydYd7UQbF64DxqB6fq7ZaJWg> <xmx:TaWCaeE157g0VdgQgXGch7tdgo25M__3wSuqwu6zfvm3b0-BVGKLfTt9> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 3 Feb 2026 20:47:55 -0500 (EST) Message-ID: <93e69553-aad9-4ff4-9190-cd3671b1897b@HIDDEN> Date: Wed, 4 Feb 2026 03:47:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers To: Stefan Monnier <monnier@HIDDEN> References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <c717c2e5-f0bf-47c0-b9b6-a8bd5dfe6203@HIDDEN> <jwvldh9u7n1.fsf-monnier+emacs@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <jwvldh9u7n1.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80286 Cc: Eli Zaretskii <eliz@HIDDEN>, 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On 03/02/2026 18:38, Stefan Monnier wrote: >> FWIW, fiddling with a "future-blocking-wait" like feature, I figured that it >> will either need to use a separate thread per computed value, or use >> accept-process-output. And threads have problems with error propagation > > FWIW, error propagation doesn't seem to be a problem for my `futur` > library, because in any case I have to catch errors, stash them as the > "result" of the future, and propagate them by hand Ah yeah, that makes sense: having the library's containers run code would mean that they can/should install error handling wrappers as well. > (I think this is > inevitable: the thread level can't know where the error may need to be > propagated. In general they may need to be propagated to several > places). Certainly. But just to tie that in with the older discussion, though: I think thread-join could be called from several places too, and could signal error in all of them. >> Whereas 'condition-wait' not running timers makes more sense from a general >> experience programming with threads, like a consistent design choice. Maybe >> we could change it, of course (could condition-wait behave more closely to >> accept-process-output from the caller thread's POV: spinning and allowing >> things to run until the resource is available?) > > My current thinking in this area goes in two directions (not necessarily > mutually exclusive): > > - Maybe Emacs should have an internal C thread (not reflected as an ELisp > thread) that receives notifications like timer signals, process-status > changes, incoming process output, etc... Makes sense. > It wouldn't run any of the associated ELisp code but would just propagate > the notification the ELisp threads. > The idea would be that we could then extend timers and sentinels with > the functionality of doing a `condition-notify` instead of running > code, in which case that internal C thread could directly perform the > `condition-notify` without having to wait for an ELisp thread to be > ready to run ELisp code. > [ Not sure it would provide the functionality my library needs, tho. ] It sound interesting in a way that it could increase parallelism by being able to avoid running Lisp code in more cases. Not sure how I feel about that - running Lisp is generally a good idea to me. IIRC Spencer was describing a somewhat related scheme involving threads, process sentinels and condition variables (with threads being spawned together with processes). I can't find a full description right now, but this might be relevant: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79333#14, in case you missed this thread. (4th paragraph from the bottom: suggestion to have condition-wait call wait_reading_process_output). > - Add a new function that combines `condition-wait` with > `accept-process-output`. An accept-process-output loop that returns as soon as a condition variable is notified? Makes sense. If we had a-p-o were improved to return fast reliably, though, I would probably start with implementing a poor version of this with an a-p-o loop and a plain Lisp variable.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 4 Feb 2026 00:40:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 03 19:40:19 2026 Received: from localhost ([127.0.0.1]:52794 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vnQwN-0001up-AN for submit <at> debbugs.gnu.org; Tue, 03 Feb 2026 19:40:19 -0500 Received: from fout-a5-smtp.messagingengine.com ([103.168.172.148]:33963) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1vnQwL-0001uB-5A for 80286 <at> debbugs.gnu.org; Tue, 03 Feb 2026 19:40:17 -0500 Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfout.phl.internal (Postfix) with ESMTP id 0018FEC0317; Tue, 3 Feb 2026 19:40:11 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-10.internal (MEProxy); Tue, 03 Feb 2026 19:40:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1770165611; x=1770252011; bh=WtEA5Szfc9p/L1bbU/7nLTTHbFVzkn6S8zHQtZI/TLk=; b= TWD2ZBL4lW6gxqWb086gkQvPUgncFzsEaO2YjpWpwS7doixCjyj+tmawyyassDiM NC1JE0ITeWojz42LvfHj4ng7LA047+2IlJXk/+Fv1dkPlyaSZVb7e200UVIqfeiW 2I2RwC6hbXynkCTugLpXwaluCRYlCQJRuqsbE8laFdjz+3kqTkfomC1jFfqeVdgJ 3I/20hRkinhLYi++ndwcm1DD28jhxY54mXj4SPb4rhlY4sP7khvAra5Df1F0kXE9 oobFjzuILUZqQODyP4WGTBd1gFStKqeBYdz9Ub+PaIu1kXZwUTLCoyZkVDg8Yvh0 8E1Svc7oLuyJbuOtraW/ZA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1770165611; x= 1770252011; bh=WtEA5Szfc9p/L1bbU/7nLTTHbFVzkn6S8zHQtZI/TLk=; b=S tK7BkewtPQ18a3jri/hTC4JQWYD5D8d82Y/B9Yrja98Qf2BWCPUtiaYLBGuuvgI8 nW/l8ZMxx+5kWXMIwWU4Xyq6n3rS9+/bMl4jq3tPurIyfK53L4veXxLa0QNhTAlY j0mNeEmMuaOKRZ47R6Sk/QF8PkF4Smhi33SgKvQWa3+pG6NRBxB83Xpo2i9Xar9k Xl0qF3V72ltwSz1IPRhylCC4QNuu4DamMcbAFZpRETOWxlDhv7gYCujdlOrGBgW3 2QtwPo/jyEuysr+IFrMBBM7FN660A3nxd8PKXWk0tT8g26eu/09UeNQj2CTq+wNe w4PZdEBdeHHbbz1UlcPfg== X-ME-Sender: <xms:a5WCaYYJ8RGqD4tEaOJ1st0h3qtmAZehGMjkDt5KmgrH5qqQQbcX2g> <xme:a5WCac2n-NrhQ5uW-qmKKHh6ZdKrGh6UjIJrSb4kLmtBgVApDzUeGdeUX4L7Eoz5B zXVlC9qzsSAqBuQRCtiGziRNjRhu7xHLySJJpN_TfyQRI0c1QYoDe9B> X-ME-Received: <xmr:a5WCaSjuM2hG7SguUe9K8nlkDeiwaCYU1SJ9agNAal2Wi2-gQjKnbqS11Lqje1sjA5ej> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddukeduhedtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhr hicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvg hrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedujeeh necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmih htrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhp ohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehmohhnnh hivghrsehirhhordhumhhonhhtrhgvrghlrdgtrgdprhgtphhtthhopeektddvkeeisegu vggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepjhhohhhnfiesghhnuhdrohhrgh X-ME-Proxy: <xmx:a5WCaYZq38qfTs0InW5PbZduB-sYFZlxA2lJ5ykm06sp7bjHw2V-Rg> <xmx:a5WCaaSliZ34-EFz_1aK4oKAK71Pvm37y9PX065UpoBji7Riks8HFQ> <xmx:a5WCabRxr0z11iV756hQ5w3JDLyc1yqPpnJgA6jDLm6TL1v9BW6hiw> <xmx:a5WCaeRLbLbBPfB-6g4oYpVvcx8NAlhApLrj-O1GUfqBNwx9OHMCTQ> <xmx:a5WCaScnBVMIolskhuMRFmBh2mllzcMT5KSjjLA3kd_2KuMSzlHUONUi> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 3 Feb 2026 19:40:10 -0500 (EST) Message-ID: <ab18a460-6eea-4b4b-88b6-f321149e37df@HIDDEN> Date: Wed, 4 Feb 2026 02:40:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers To: Eli Zaretskii <eliz@HIDDEN> References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <c717c2e5-f0bf-47c0-b9b6-a8bd5dfe6203@HIDDEN> <86cy2m103w.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <86cy2m103w.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, monnier@HIDDEN, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Hi Eli, On 03/02/2026 14:29, Eli Zaretskii wrote: >> Date: Tue, 3 Feb 2026 04:35:24 +0200 >> Cc:80286 <at> debbugs.gnu.org,johnw@HIDDEN >> From: Dmitry Gutov<dmitry@HIDDEN> >> >> Personally, these two things (thread-join not signaling error and a-p-o >> waiting too long) seem more like bugs to me. > Yes, Lisp threads in Emacs are just one huge bug area. IMHO that kind of statement should imply that threads could use a lot of rework, including even changes in semantics. More so anyway than most other code with long history, in other parts of Emacs. > (Runs for cover.) No argument, really.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 3 Feb 2026 16:38:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 03 11:38:16 2026 Received: from localhost ([127.0.0.1]:48598 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vnJPs-0004uY-4z for submit <at> debbugs.gnu.org; Tue, 03 Feb 2026 11:38:16 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:36115) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vnJPq-0004uM-At for 80286 <at> debbugs.gnu.org; Tue, 03 Feb 2026 11:38:14 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DFCE6441D7A; Tue, 3 Feb 2026 11:38:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1770136687; bh=prYt7MsdfM+ppN5rTfXEGhijufRyqYMsgtN2Wzf3qQo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=pUklyYiX2UFVwcGAejTT3uoR2H5CMz+OjHz1vtbQYdvkpaSjfI1Zx5e4TXWnwm/Mu tta0iKyApA1FVbV+sJT4rA/Q4vhFtLVEtfxmtF1Eul7HSqA/P5/lKgtKA/vz3uozmM To6hkgCCtj9lhlMcz0LPUs2Y0nMzSRq4S2WUyW+OFbC9xJ6S1FIVcz27oY3IYbXHBC pe+NxHNgXNI1Uo4421vCdEBjzkSlYKJ88Kd3zq0njP3RiLZkzi23MiTcRhxwjDenSV ahcWX3Dyy2huy1qtgDOWpSYBGrgb+WF0sIT+oDMa6ocdogALb18DchkTJFtxbdoabW uzpib/lwpv6bA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BDF79441D6D; Tue, 3 Feb 2026 11:38:07 -0500 (EST) Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8C706120821; Tue, 3 Feb 2026 11:38:07 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers In-Reply-To: <c717c2e5-f0bf-47c0-b9b6-a8bd5dfe6203@HIDDEN> Message-ID: <jwvldh9u7n1.fsf-monnier+emacs@HIDDEN> References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <c717c2e5-f0bf-47c0-b9b6-a8bd5dfe6203@HIDDEN> Date: Tue, 03 Feb 2026 11:38:06 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.047 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: Eli Zaretskii <eliz@HIDDEN>, 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > FWIW, fiddling with a "future-blocking-wait" like feature, I figured that it > will either need to use a separate thread per computed value, or use > accept-process-output. And threads have problems with error propagation FWIW, error propagation doesn't seem to be a problem for my `futur` library, because in any case I have to catch errors, stash them as the "result" of the future, and propagate them by hand (I think this is inevitable: the thread level can't know where the error may need to be propagated. In general they may need to be propagated to several places). > Whereas 'condition-wait' not running timers makes more sense from a general > experience programming with threads, like a consistent design choice. Maybe > we could change it, of course (could condition-wait behave more closely to > accept-process-output from the caller thread's POV: spinning and allowing > things to run until the resource is available?) My current thinking in this area goes in two directions (not necessarily mutually exclusive): - Maybe Emacs should have an internal C thread (not reflected as an ELisp thread) that receives notifications like timer signals, process-status changes, incoming process output, etc... It wouldn't run any of the associated ELisp code but would just propagate the notification the ELisp threads. The idea would be that we could then extend timers and sentinels with the functionality of doing a `condition-notify` instead of running code, in which case that internal C thread could directly perform the `condition-notify` without having to wait for an ELisp thread to be ready to run ELisp code. [ Not sure it would provide the functionality my library needs, tho. ] - Add a new function that combines `condition-wait` with `accept-process-output`. === Stefan
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 3 Feb 2026 12:30:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 03 07:30:00 2026 Received: from localhost ([127.0.0.1]:44041 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vnFXb-0006jm-1r for submit <at> debbugs.gnu.org; Tue, 03 Feb 2026 07:30:00 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57164) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vnFXY-0006io-Lp for 80286 <at> debbugs.gnu.org; Tue, 03 Feb 2026 07:29:57 -0500 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 <eliz@HIDDEN>) id 1vnFXT-00009g-DG; Tue, 03 Feb 2026 07:29:51 -0500 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=Be0jCzH9NQYpMpo9rzDpAEDh3vfj7DEVe267KeadO0M=; b=BJewm6fKr00x MLExFDQHBRj/wAxOQhN42g1NfbzlU6BRatfD8YPUHzRnUlHuU9+7syk0RAv/BcZUAJCkGlpQIxr8f HWISSLcn9XtJc71FuyrfbvlM5c0D9Smkl+BCIxrbKiAok1j0aO5GasPa0zxnqKoar8dVp9hHcy69t gJ3xNnNwwn7hBuAdJwS6eGzPMSGWTuqG5YNZPRoQvQVRLXPmhsddLfL7XSZm6dr9pU8UwilacEnpJ bPtfcWIJn4rnefFlclrf/yinmN8gybwlkDnbTWJ7OalrONjMJoDHKmPlfDX27MEHmwXn4NrxaIhBY CfNw5kdxQU0Czmk+iXR/Vg==; Date: Tue, 03 Feb 2026 14:29:39 +0200 Message-Id: <86cy2m103w.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <c717c2e5-f0bf-47c0-b9b6-a8bd5dfe6203@HIDDEN> (message from Dmitry Gutov on Tue, 3 Feb 2026 04:35:24 +0200) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <c717c2e5-f0bf-47c0-b9b6-a8bd5dfe6203@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, monnier@HIDDEN, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Tue, 3 Feb 2026 04:35:24 +0200 > Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN > From: Dmitry Gutov <dmitry@HIDDEN> > > Personally, these two things (thread-join not signaling error and a-p-o > waiting too long) seem more like bugs to me. Yes, Lisp threads in Emacs are just one huge bug area. (Runs for cover.)
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 3 Feb 2026 12:28:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 03 07:28:23 2026 Received: from localhost ([127.0.0.1]:44022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vnFW3-0006e8-CW for submit <at> debbugs.gnu.org; Tue, 03 Feb 2026 07:28:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46804) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vnFW1-0006dF-36 for 80286 <at> debbugs.gnu.org; Tue, 03 Feb 2026 07:28:21 -0500 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 <eliz@HIDDEN>) id 1vnFVv-0007tS-Ke; Tue, 03 Feb 2026 07:28:15 -0500 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=s9f063CGIgbH/Mro2dOhNuF5i9W9sMSfSEhQ1Ybp7/I=; b=WKYjVajK5uFV aEbyKL2TqRYoKQGShHvLYbGjvczFe8IZPD9I16pgB3IFM2e6CzCP9+C8AnAjZUjt3ReGmwlb1dFyI 08iixq5A+ZGOD8hHJ93To53ZlZ1UrJfL78amYXfSguImRLueoCuXtPWq9vdTFDoesCB690V/G6pJi wectKDOK+ELklj3DHL+TTzLxJ6XtidhYpADFJWZFkGRe4eVbH2w2HU0lbqltz1ndRgs1afmEqBJjL /u4lMSXKhD6N0n3opEPdLYrn+DvFlDXJ4FgO5zEPqT+WSXha1Fl4UMidqCz0aoAs1L9qerF5yiUAb sEEnRPyBgZwQR+sh3z72Fw==; Date: Tue, 03 Feb 2026 14:28:12 +0200 Message-Id: <86ecn2106b.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <ef7c216d-8c5b-44aa-9b9d-d396aeb5484c@HIDDEN> (message from Dmitry Gutov on Tue, 3 Feb 2026 03:02:09 +0200) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <ef7c216d-8c5b-44aa-9b9d-d396aeb5484c@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, monnier@HIDDEN, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Tue, 3 Feb 2026 03:02:09 +0200 > Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN > From: Dmitry Gutov <dmitry@HIDDEN> > > On 31/01/2026 09:54, Eli Zaretskii wrote: > >>> More specifically, the author can choose between different harms: either > >>> an occasional undesirable delay when exiting, or an undesirable constant > >>> spurious activity if the delay is made short enough not to be annoying. > >> Not if the author writes a Lisp program which doesn't have these bugs. > > Btw, we could perhaps detect the situation where condition-wait is > > called when there's only one thread in the list of threads, and signal > > an error in that case, which would prevent the deadlock. But somehow > > my impression was that this is not the solution you are looking for. > > That reminds me of what I read about deadlock detection in Go. > > Irrespective of whether it serves the immediate goal for working > "future" primitives, it might be a good thing to do. I don't think Stefan liked the idea.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 3 Feb 2026 12:20:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 03 07:20:32 2026 Received: from localhost ([127.0.0.1]:43914 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vnFOS-0005zP-Ad for submit <at> debbugs.gnu.org; Tue, 03 Feb 2026 07:20:32 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46120) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vnFOO-0005ya-UV for 80286 <at> debbugs.gnu.org; Tue, 03 Feb 2026 07:20:30 -0500 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 <eliz@HIDDEN>) id 1vnFOI-0004qp-13; Tue, 03 Feb 2026 07:20:23 -0500 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=UsQ0z6zlSlTBzJBmoWboJSHacdoY9V9Ct4Um6XhiaFI=; b=FZQPu/ZeNjAi U6POOawpFnHhBALPHjQ+MYfU0PjD3yukHgKkLsC4dZON19woy6AuarxVZedq4Qjv+KHnopGVwcfGe UIOfKiqSkybbmQ0gThsB7E+o7k0h1iMgFGDGgy3TMbi0scCfM7mHPQywBzMAvFlEBJI6FDSLr5TqY ysbfDGmgn/bCdTTz7kclrpcHacAz/krNnLtwoPrV86wSjMqgfirKkc6CY/Wi5p2hcBmzWRpSffceh 4n+dMWXLBNweB5HYIOjogujJek4uQvjAb6OyAsdfdhdpfIPIw3XDZA8vm5er8ZssAnGDdEX8/E6xd 0/i/aZgP3MrXGoKmtrKUGw==; Date: Tue, 03 Feb 2026 14:20:19 +0200 Message-Id: <86ikce10jg.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvqzr23oi0.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Mon, 02 Feb 2026 15:03:15 -0500) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86zf5t4smf.fsf@HIDDEN> <jwvy0lcfqca.fsf-monnier+emacs@HIDDEN> <86y0lc31c7.fsf@HIDDEN> <jwvms1sfng2.fsf-monnier+emacs@HIDDEN> <86qzr42rzj.fsf@HIDDEN> <jwvms1ret7j.fsf-monnier+emacs@HIDDEN> <86343j2qjr.fsf@HIDDEN> <jwv1pj3chje.fsf-monnier+emacs@HIDDEN> <86pl6n152t.fsf@HIDDEN> <jwvqzr23oi0.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN > Date: Mon, 02 Feb 2026 15:03:15 -0500 > > >> > If this is about thread-signal, then I could argue that it already > >> > behaves like C-g: you cannot interrupt certain syscalls. > >> > >> That's not answering the question: > >> > >> based on the documented behavior of the functions, do you think the > >> implementation should better try to make sure the test succeeds, or > >> try to make sure it fails? > > > > It makes no sense to me to expect from thread-signal something that > > C-g doesn't do. So the test as written cannot succeed, at least not > > unless short-interval timers are running when the test runs. > > [ Why don't you want to answer the question? ] But I did! I said "test as written cannot succeed". That answers your question directly. > OK, here's an alternative question, then: > > based on the documented behavior of the `accept-process-output`, do > you think the implementation should try to make sure it reacts > as-soon-as possible to `C-g`, or do you think it should try to > preserve the current occasional delay? As you have already discovered, this already happens if the thread running accept-process-output monitors the keyboard input as well. My answer to your question is "accept-process-output should react to a signal as soon as possible, provided that it (the thread) runs".
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 3 Feb 2026 03:29:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 02 22:29:04 2026 Received: from localhost ([127.0.0.1]:38481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vn768-0002f8-4O for submit <at> debbugs.gnu.org; Mon, 02 Feb 2026 22:29:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47276) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vn765-0002eQ-8L for 80286 <at> debbugs.gnu.org; Mon, 02 Feb 2026 22:29:02 -0500 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 <eliz@HIDDEN>) id 1vn75z-00030u-84; Mon, 02 Feb 2026 22:28:55 -0500 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=m0TwzRPW3niIIk6qvZ119liW9jrgNw8RTeCFt1YgCHw=; b=D8hFJA08LF0G OtOEsOUdhcAGuVtWc9VmaOwsDQCWjI2Ny5EUHVzZ+C9eNUndto2kOSGA4EaLNTUJ7W5VD0jjec6Gf 6ZqiO9fw/BpGW6gc+lBuCptWnpuzq6W8Dwmr6vbQKuSeDcEFbrYd3jR+kvlY064xY6Q65NeCGo5oR jy5dzsYzZBlHRWpUIzA3jBMz8tm0Me9qwik2kTqGxoATLcF5or9cDziMrMNOletm4F6XTywIjIWIL AvosuW7H1NNfX0XBafFj5SBxWJ8XmDEJgUNpwQxSaj3UEI6VGb1t2Ip9Jn0RDN0S+pZy8aGby8EOM X9dMF+/dGn7T8vd0YnXYxw==; Date: Tue, 03 Feb 2026 05:28:51 +0200 Message-Id: <86jywu1p58.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvfr7i3mza.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Mon, 02 Feb 2026 15:35:52 -0500) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86zf5t4smf.fsf@HIDDEN> <jwvy0lcfqca.fsf-monnier+emacs@HIDDEN> <86y0lc31c7.fsf@HIDDEN> <jwvms1sfng2.fsf-monnier+emacs@HIDDEN> <86qzr42rzj.fsf@HIDDEN> <jwvms1ret7j.fsf-monnier+emacs@HIDDEN> <86343j2qjr.fsf@HIDDEN> <jwv1pj3chje.fsf-monnier+emacs@HIDDEN> <86pl6n152t.fsf@HIDDEN> <jwvfr7i3mza.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN > Date: Mon, 02 Feb 2026 15:35:52 -0500 > > > It makes no sense to me to expect from thread-signal something that > > C-g doesn't do. > > BTW, when does C-g not interrupt immediately `accept-process-output`? > I can't seem to find a scenario where that happens. Both in a fresh GUI > and a fresh tty session, `M-: (accept-process-output nil 10)` followed > by `C-g` returns immediately without waiting even a fraction of > a second, AFAICT. So would you like to reword your question now, before I "don't answer" it?
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 3 Feb 2026 02:35:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 02 21:35:36 2026 Received: from localhost ([127.0.0.1]:37893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vn6GN-00061Q-Ph for submit <at> debbugs.gnu.org; Mon, 02 Feb 2026 21:35:36 -0500 Received: from fout-a7-smtp.messagingengine.com ([103.168.172.150]:34511) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1vn6GK-00060T-Iy for 80286 <at> debbugs.gnu.org; Mon, 02 Feb 2026 21:35:34 -0500 Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfout.phl.internal (Postfix) with ESMTP id 679BCEC026B; Mon, 2 Feb 2026 21:35:27 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-12.internal (MEProxy); Mon, 02 Feb 2026 21:35:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1770086127; x=1770172527; bh=ZwIakHsPNEPAXdJ/bO16h6yFtD4ZnIhbRlUXJAYhvgw=; b= L+II7rfCH5HdPBcYEPONpsp03R4fi2b0ZNQOqyTIpOWcliVJxaGuTr8KKM4BZ9kh X/YI0EMIfwlJv9y2TxxrDuJJsfoBxG9fqj4yYKLWN4i1oFslCygrNfedrxmRn4mV y7yCXR57MqMwZaHC8RdWutY+qM8rT4Yln3XNEbjkYAH0RP0dXJKkegslPQX9/f+V /z3D23G9TigcYIUFer9tp4jEc/1DrJPTJReZ/VA0uSToCwUwR+Lfb98IWE8MBOqm tX3lK7aMab9NAG1sdhyjWlEkCZAZ+gSNRJsZCHCuvpKHZmTNdhB885j96i2bQBN9 xnSw3joxR1mgCrZTsV2Eyw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1770086127; x= 1770172527; bh=ZwIakHsPNEPAXdJ/bO16h6yFtD4ZnIhbRlUXJAYhvgw=; b=S KSnMxNAuR/lPVzQkonkkTryqv6MJplTkUQxtTJ7xM8IWk4xZEKq1+hI8jyuYKMNT l+nPc1mPxoFMARv3BfMexvNU2QejRXmq5GxPnvegvuJw96fOAYPHdwjPoJWdRtic peLd3hu6HRPIBi9HfdcxQFV0xFdAdcTNzBus7zpm/uyWzKr3Oz5xMKzwITxkx9oF 5X3ooF82KUHKCVbSazym29ug8+yUIjiD/ZGpjTVjLTP9hNVGD8YHT7meVFtxpsAC H+TDX51xC5sg01rybPi+DTisAD9dltqQYm1MoZcgPHbQsm9/1FcFMZWjbH+Rkeqs lZpPrLZ8ks/mGKQwnXngA== X-ME-Sender: <xms:716Baf4j3yUDJtSqG9haUTNlYYWWbxsIod3yuLlaIQ_WYcCExMgqGg> <xme:716BaSuVoOU2EFm72XDOvYhtY3xbZ7EqKoVEicAUQPactjDYFx_0_-cPsl5EEQR7y D-vj0JZzVn5VQsgcvcP5gmHWz8H6EvuERkY9HgFy7o_ov7yLXEVK8A> X-ME-Received: <xmr:716BaQ5bSYYonee2hudwp_akvp47xq12M1yWWNkhPzbxgeRqXR6mMVCVNetQzs1nNOUe> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddujeelfeduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhr hicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvg hrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedujeeh necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmih htrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhp ohhuthdprhgtphhtthhopehmohhnnhhivghrsehirhhordhumhhonhhtrhgvrghlrdgtrg dprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopeektddvkeeisegu vggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepjhhohhhnfiesghhnuhdrohhrgh X-ME-Proxy: <xmx:716BadWmiHggbW3bcSBbqSWMuUfxmGcgVmovaCdcQ84TLSnuwpCg3g> <xmx:716BaS96WSLvzmGXHFCkDZnRVowARSgXi4tbaFks7bXFk_mZKTtWLA> <xmx:716BaZkmYISXydV9FW7IbN-3nzNK5WGdO3SQrtJnAs53sjoxgiwBqw> <xmx:716BaQV4vKVxjFh7jQscRGENt1iMOQvEMiPZTV36YoDfqTnQ3DN_2g> <xmx:716BaVLbLCWZiL4SbZx0RuTsVZ-Vu1Tb4KpW0s5YIckk1v8CfpBLkyv8> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 2 Feb 2026 21:35:26 -0500 (EST) Message-ID: <c717c2e5-f0bf-47c0-b9b6-a8bd5dfe6203@HIDDEN> Date: Tue, 3 Feb 2026 04:35:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers To: Stefan Monnier <monnier@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On 01/02/2026 17:14, Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: >> We have so many other, simpler ways of doing that, and so I wonder why >> should we be bothered by this strange use case? > The concrete use-case where it showed up is > `futur-blocking-wait-to-get-result` (below, excerpted from > a WiP future/promise package). FWIW, fiddling with a "future-blocking-wait" like feature, I figured that it will either need to use a separate thread per computed value, or use accept-process-output. And threads have problems with error propagation (among other things), while a-p-o might do more busy waiting (like you describe in the subsequent paragraph) - not great, but at least safer than than the other options. Personally, these two things (thread-join not signaling error and a-p-o waiting too long) seem more like bugs to me. Whereas 'condition-wait' not running timers makes more sense from a general experience programming with threads, like a consistent design choice. Maybe we could change it, of course (could condition-wait behave more closely to accept-process-output from the caller thread's POV: spinning and allowing things to run until the resource is available?)
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 3 Feb 2026 01:02:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 02 20:02:21 2026 Received: from localhost ([127.0.0.1]:36993 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vn4o9-0006cx-2R for submit <at> debbugs.gnu.org; Mon, 02 Feb 2026 20:02:21 -0500 Received: from fhigh-a1-smtp.messagingengine.com ([103.168.172.152]:51257) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1vn4o6-0006cd-LB for 80286 <at> debbugs.gnu.org; Mon, 02 Feb 2026 20:02:19 -0500 Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfhigh.phl.internal (Postfix) with ESMTP id 38B5014000FB; Mon, 2 Feb 2026 20:02:13 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-10.internal (MEProxy); Mon, 02 Feb 2026 20:02:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1770080533; x=1770166933; bh=fQ8h4pTpQtrsMxro7WlA34/+hyIY0lDlSlU0P90UM7c=; b= ASbiPuiIIfl43PjQ4GEirheDeUIPYp8PMtJSK7XMCU7DjS893CVeeW9QYyo9GPcI kcMKAGoIE5m08o9oaRTimyInvwRygxpIii4dz2DAlO9MudL4SUB5qjD907lSOYo3 Wb27SFu4knhFPsVyKa9KcxxuYCOR1L7JJi3p23WQbq7sw9cD5GhYcEZsbHQxt4CN VPBNgGkY8hIyutHxp4SFVrBzIViE+zva11dNToHgA1AMInDKXF+1wmGrPNQMTSTv h5cGypoAJ23yX4Jk5MHCY/cYa8lEtNLnpPpOOuAYj1qCPKMvgGg/l8hHJD7zDTeg 0/bd6tI4CjDj5ha8tcsFlw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1770080533; x= 1770166933; bh=fQ8h4pTpQtrsMxro7WlA34/+hyIY0lDlSlU0P90UM7c=; b=R FYo0u522oNqCM4xUCKp3jnzSmO496PhbHV0cwln/vnOxAC4MpF/BaYW1J3MzhJg/ FUk+akKw0/f0P2X7QBU1Hy4uawaBReYazeM9wW3wqFGnc6E2MF4Gv7qglbIGn9Bu S34nymtHOZ+TgqCVAKnfl8w8YM25Pz4DosjNRnEnhTfFtc2k7hIl1WSWi0cCwXFX i/ugo7XCiIWsuTJUy7TdQQT6Lv0ypB1Ggd4MQCXLLKcbB/fvkqp+NiIzz6MiOgdW cBjNosZ6fGwjVZohFNN/XcLs/QKYyvSGbmHoa6BqG228aK1MuV42MLu+v4AdoI5c 3GapiijmkYznpS2HVF4QQ== X-ME-Sender: <xms:FEmBaXLh1sC0zdK9pWmiFO57vRs5RbmPTuzeLSOnt2bEtkLnRfc93A> <xme:FEmBaY93QrQGWOqt8GU1VYtJtCQVm0OtcI8KWgQKk8IppDU5RRyhmyNXlrTxh4QKw 0DYgM4g4n9Qorwh9goDKIgN0ybgv7RrPMt-huOGU49rybyCQan62Vjm> X-ME-Received: <xmr:FEmBaaKXzF6fLgvPWNYi9KKLsMpyIGrxvZP_1nNBf46D1swjlvQpIFHmddaeT2ePAwj2> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddujeeludegucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhr hicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvg hrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedujeeh necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmih htrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhp ohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehmohhnnh hivghrsehirhhordhumhhonhhtrhgvrghlrdgtrgdprhgtphhtthhopeektddvkeeisegu vggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepjhhohhhnfiesghhnuhdrohhrgh X-ME-Proxy: <xmx:FEmBadlpRsExer988Satlnysk2DomwcDXkgE5IX4eAXHpuVX1fr6jg> <xmx:FEmBaeMaC9jwxc75NPZO3UlA3efclbqR5NIKYO2NxR5TIlsAzotWQg> <xmx:FEmBaT1LU7XIUB3A8tDMKmaPmSj8M6wLDFXgyc2KPqc5rE6rjwYV-g> <xmx:FEmBadlpXu_HUQ__EmqTVW_gQiwsI9VFa0ggSw4Dvtehg2xt_R3srA> <xmx:FUmBaea-kNKak7dFFxzZFrBYgzYVvItBgxFP7DSfek5qQNq9a_HLGWIJ> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 2 Feb 2026 20:02:11 -0500 (EST) Message-ID: <ef7c216d-8c5b-44aa-9b9d-d396aeb5484c@HIDDEN> Date: Tue, 3 Feb 2026 03:02:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers To: Eli Zaretskii <eliz@HIDDEN>, monnier@HIDDEN References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <86tsw26wuy.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On 31/01/2026 09:54, Eli Zaretskii wrote: >>> More specifically, the author can choose between different harms: either >>> an occasional undesirable delay when exiting, or an undesirable constant >>> spurious activity if the delay is made short enough not to be annoying. >> Not if the author writes a Lisp program which doesn't have these bugs. > Btw, we could perhaps detect the situation where condition-wait is > called when there's only one thread in the list of threads, and signal > an error in that case, which would prevent the deadlock. But somehow > my impression was that this is not the solution you are looking for. That reminds me of what I read about deadlock detection in Go. Irrespective of whether it serves the immediate goal for working "future" primitives, it might be a good thing to do.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 2 Feb 2026 20:36:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 02 15:36:08 2026 Received: from localhost ([127.0.0.1]:34518 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vn0eV-0006RR-E7 for submit <at> debbugs.gnu.org; Mon, 02 Feb 2026 15:36:07 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38307) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vn0eS-0006QU-Nj for 80286 <at> debbugs.gnu.org; Mon, 02 Feb 2026 15:36:06 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A377A441CEB; Mon, 2 Feb 2026 15:35:58 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1770064557; bh=ineTUwmQf4VMY/UHiD0YbR7YoR8/cw48yjS9ym1/alc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Afa9kaig9RHGMlvxeBIGmPqkqVgxh1tpB2ycqFq4Dl2mgFxbzPBsEdgNNPKVpDKiN aiSsYQHViM85Nir5XerPGj3u2FunY6sSxwX/dYxuLyXKjQgUI8U/GFXdyLCRnLfIJL UKoV3ma+1aXEApSjglQd77F1I0QuzAr+jOh4grHrhB6Qu1s+b25vVc0UX7BNVvcf2u 0V2voLy6w39b3Txa24iVu0sPRMujy2hsJuGI7CDXZU2CWwFw2WBpoCudV5+V+XDVwL GQ+xuE43Vh/F+/Qy0NthEJN6gnOku5BFpf5+zr4WY7Ue1sPJQd7Sdpqe6tMHd/puQq 0Y40ZKudwyACg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id ACF54441CE7; Mon, 2 Feb 2026 15:35:57 -0500 (EST) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9201E1205E8; Mon, 2 Feb 2026 15:35:57 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers In-Reply-To: <86pl6n152t.fsf@HIDDEN> Message-ID: <jwvfr7i3mza.fsf-monnier+emacs@HIDDEN> References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86zf5t4smf.fsf@HIDDEN> <jwvy0lcfqca.fsf-monnier+emacs@HIDDEN> <86y0lc31c7.fsf@HIDDEN> <jwvms1sfng2.fsf-monnier+emacs@HIDDEN> <86qzr42rzj.fsf@HIDDEN> <jwvms1ret7j.fsf-monnier+emacs@HIDDEN> <86343j2qjr.fsf@HIDDEN> <jwv1pj3chje.fsf-monnier+emacs@HIDDEN> <86pl6n152t.fsf@HIDDEN> Date: Mon, 02 Feb 2026 15:35:52 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.251 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > It makes no sense to me to expect from thread-signal something that > C-g doesn't do. BTW, when does C-g not interrupt immediately `accept-process-output`? I can't seem to find a scenario where that happens. Both in a fresh GUI and a fresh tty session, `M-: (accept-process-output nil 10)` followed by `C-g` returns immediately without waiting even a fraction of a second, AFAICT. === Stefan
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.
Received: (at 80286) by debbugs.gnu.org; 2 Feb 2026 20:03:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 02 15:03:30 2026
Received: from localhost ([127.0.0.1]:34088 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vn08w-0004D9-6F
for submit <at> debbugs.gnu.org; Mon, 02 Feb 2026 15:03:30 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:31877)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vn08t-0004Co-RF
for 80286 <at> debbugs.gnu.org; Mon, 02 Feb 2026 15:03:28 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E972E441CDD;
Mon, 2 Feb 2026 15:03:20 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1770062599;
bh=BGNNqClKwuJdojDGqpT/tTVbq4obocOoAS5/lgxHi9c=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=iwlf/N/3qaHxPs9WzlpYDFZuh0wfAzLl3Hvnc3tDj6J96khgUHrjA7a8Dp85OWoBD
mO31b7++R1ndz2WQGkK9Y2ZG4VExbzyzZgNkjUy23N/cidKb+RxkiOc93qPGzbV+Ox
GoCrGMwzCZfTf5ndopIrFp/BAWA/IunVDyaRNbh9Wi1cnQzoTx2PUA0LppBOxtZYuI
iAgOYqL1+jYJiiN2fCy+gS3OcPx4WMuYJVVpCv2rNoL6+Xw7q1XCTPYCv6XT944yA9
FZgxgYaEbWAXXAWFA4Qeq0xtfPIbZ/8oZ/SaSl0bFEvV4QyrpGfprQA5JZZL6qvXGt
OxEfK7T5U+hGg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DA125441CDA;
Mon, 2 Feb 2026 15:03:19 -0500 (EST)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C995A120B79;
Mon, 2 Feb 2026 15:03:19 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers
In-Reply-To: <86pl6n152t.fsf@HIDDEN>
Message-ID: <jwvqzr23oi0.fsf-monnier+emacs@HIDDEN>
References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN>
<jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86zf5t4smf.fsf@HIDDEN>
<jwvy0lcfqca.fsf-monnier+emacs@HIDDEN> <86y0lc31c7.fsf@HIDDEN>
<jwvms1sfng2.fsf-monnier+emacs@HIDDEN> <86qzr42rzj.fsf@HIDDEN>
<jwvms1ret7j.fsf-monnier+emacs@HIDDEN> <86343j2qjr.fsf@HIDDEN>
<jwv1pj3chje.fsf-monnier+emacs@HIDDEN> <86pl6n152t.fsf@HIDDEN>
Date: Mon, 02 Feb 2026 15:03:15 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.253 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80286
Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> > If this is about thread-signal, then I could argue that it already
>> > behaves like C-g: you cannot interrupt certain syscalls.
>>
>> That's not answering the question:
>>
>> based on the documented behavior of the functions, do you think the
>> implementation should better try to make sure the test succeeds, or
>> try to make sure it fails?
>
> It makes no sense to me to expect from thread-signal something that
> C-g doesn't do. So the test as written cannot succeed, at least not
> unless short-interval timers are running when the test runs.
[ Why don't you want to answer the question? ]
OK, here's an alternative question, then:
based on the documented behavior of the `accept-process-output`, do
you think the implementation should try to make sure it reacts
as-soon-as possible to `C-g`, or do you think it should try to
preserve the current occasional delay?
=== Stefan
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 2 Feb 2026 16:30:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 02 11:30:14 2026 Received: from localhost ([127.0.0.1]:60089 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vmwoX-0005kL-Nh for submit <at> debbugs.gnu.org; Mon, 02 Feb 2026 11:30:14 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53362) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vmwoU-0005db-Ve for 80286 <at> debbugs.gnu.org; Mon, 02 Feb 2026 11:30:12 -0500 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 <eliz@HIDDEN>) id 1vmwoO-0007ym-GT; Mon, 02 Feb 2026 11:30:04 -0500 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=OiPjoFQCt9izUIRRQvORnviAlkKhaFiCFon+buYNGW8=; b=nUXoGPeCgqLn zZT7WKMdU6LxX0UUmLEZBJHuAwbqz4ZOLyJgZRKm35kf//gjJR+eZXjOhCkwxJctmwf7UqHHNSTv5 Q73ZNtVO0mx33wkK9PJwAgsMNExa1bn/DMbJ1JzY3dbAIDaBTzZond3IkCf7dxLLox2jG7NlVsCOx 9r33ch+y6UOm89Rbx/l43w50k2FfdKwIUJJzioA9G6XKayyOROvmmUXLkGkVn1yEaXt5ZEXkoxfrd syiUkTxNtwqfvks1+gp1LeG+Y4oICBiJ4vh4KJfZO+j5e+ZtAadNNV3XQjg2kKjHFfx9P8IGA9GJD CdHD7GVFSpOMiu/WahIjFA==; Date: Mon, 02 Feb 2026 18:30:02 +0200 Message-Id: <86pl6n152t.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwv1pj3chje.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Mon, 02 Feb 2026 10:09:03 -0500) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86zf5t4smf.fsf@HIDDEN> <jwvy0lcfqca.fsf-monnier+emacs@HIDDEN> <86y0lc31c7.fsf@HIDDEN> <jwvms1sfng2.fsf-monnier+emacs@HIDDEN> <86qzr42rzj.fsf@HIDDEN> <jwvms1ret7j.fsf-monnier+emacs@HIDDEN> <86343j2qjr.fsf@HIDDEN> <jwv1pj3chje.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN > Date: Mon, 02 Feb 2026 10:09:03 -0500 > > > If this is about thread-signal, then I could argue that it already > > behaves like C-g: you cannot interrupt certain syscalls. > > That's not answering the question: > > based on the documented behavior of the functions, do you think the > implementation should better try to make sure the test succeeds, or > try to make sure it fails? It makes no sense to me to expect from thread-signal something that C-g doesn't do. So the test as written cannot succeed, at least not unless short-interval timers are running when the test runs.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.
Received: (at 80286) by debbugs.gnu.org; 2 Feb 2026 15:09:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 02 10:09:14 2026
Received: from localhost ([127.0.0.1]:59112 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vmvY9-0000DB-Jw
for submit <at> debbugs.gnu.org; Mon, 02 Feb 2026 10:09:14 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:52468)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vmvY7-0000Cl-D4
for 80286 <at> debbugs.gnu.org; Mon, 02 Feb 2026 10:09:11 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 02CAF44147D;
Mon, 2 Feb 2026 10:09:06 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1770044944;
bh=lqvcOj6EcvDEKWHyu6tt3f0Lole+3XgWorq1SRHnGAs=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=OopsX40QhJBhtB8OIt5ziP4PvSL5cInIML5buXFlLdBLEBpBbs/dUymboR5CpVMQT
FviXB6Lr71WixkeZgOvvekuolVW2VoGi7tQpzPqTtaZkuk/qSCja2jqY4FqRk96PL/
45+zXY5FlJi8RIgW5hgqFib6/Y1pnhfed4GzWAz5kVZSWwp0D8JwbikmIzkWn0KIA3
ncOL+TgZs8WgzxvoFe+unsNMK+Y4hFhiZifexykTaEGBdKPni7J5VrCP2Cnv21os6x
DCBxJSCH1poSuqSHV9oyLpslMc6N+92miW1X/sk6ainEJE4mXAMp47JnVJzrHBUlXg
D6/9beVLfxLgw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 703DD441461;
Mon, 2 Feb 2026 10:09:04 -0500 (EST)
Received: from pastel (104-195-243-38.cpe.teksavvy.com [104.195.243.38])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 470731203A5;
Mon, 2 Feb 2026 10:09:04 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers
In-Reply-To: <86343j2qjr.fsf@HIDDEN>
Message-ID: <jwv1pj3chje.fsf-monnier+emacs@HIDDEN>
References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN>
<jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86zf5t4smf.fsf@HIDDEN>
<jwvy0lcfqca.fsf-monnier+emacs@HIDDEN> <86y0lc31c7.fsf@HIDDEN>
<jwvms1sfng2.fsf-monnier+emacs@HIDDEN> <86qzr42rzj.fsf@HIDDEN>
<jwvms1ret7j.fsf-monnier+emacs@HIDDEN> <86343j2qjr.fsf@HIDDEN>
Date: Mon, 02 Feb 2026 10:09:03 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.218 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80286
Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
[ Boy! this discussion is really frustrating. ]
>> >> IOW, I think the test below should succeed, yet it fails (well, the
>> >> reality seems more complex: when I test it in this Gnus session, it
>> >> sometimes succeeds (the probability seems related to the 0.5 argument),
>> >> but in batch or in a fresh new session it seems to fail reliably).
>> >
>> > In your example, the non-main thread is stuck in pselect for 2 sec,
>> > and C-g doesn't work when Emacs is in a syscall. So I don't think I
>> > understand your expectations.
>>
>> Before we look at the implementation, I want to discuss the intended
>> behavior, i.e. based on the documented behavior of the functions, do you
>> think the implementation should better try to make sure the test
>> succeeds, or try to make sure it fails?
> Ok, but which behavior would you like to discuss?
This subthread is specifically about "the test below".
> Is it the behavior of accept-process-output, or the effect of
> thread-signal on accept-process-output, or what condition-wait does,
> or how timers are run, or something else?
There's no `condition-wait` nor timers in that test.
> If this is about thread-signal, then I could argue that it already
> behaves like C-g: you cannot interrupt certain syscalls.
That's not answering the question:
based on the documented behavior of the functions, do you think the
implementation should better try to make sure the test succeeds, or
try to make sure it fails?
=== Stefan
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 2 Feb 2026 14:21:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 02 09:21:21 2026 Received: from localhost ([127.0.0.1]:57296 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vmuno-0005Qo-S4 for submit <at> debbugs.gnu.org; Mon, 02 Feb 2026 09:21:21 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57994) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vmunm-0005QX-M1 for 80286 <at> debbugs.gnu.org; Mon, 02 Feb 2026 09:21:19 -0500 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 <eliz@HIDDEN>) id 1vmung-0003LV-MS; Mon, 02 Feb 2026 09:21:13 -0500 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=YVh62427Oivdy7U4n3nysRIecsIKc3Ja5tdDLwMHYBk=; b=U15KGqtIPaZz sflcsq0pTobsB89h16hkvHPPnmhgIMrfwLQcFf/6VqaZX0F6qQeK18nOTRwfSnu5w9BUZ+zxQvU24 O/pztWfoYrElMxfQKw3QjE+IYP2fVuybdb+33aIB3srLENZeTdTtrKElrP0zI2/V+elHMSGpyoPeb X1Z4ROTA4O3m+pxHTn3Gn6iPrtV+WUKGRQYu/VrC/DqJTzsckOf7Oowp6IRuZ0z0jrb7f6B1MksJ1 cfcVK0ddNuGEUc6hqyW80LF7GOfrds6LRgjHlokNKRKdUZpIK3tY18CfOTMBfjF/T+pMXAmzyz0x/ a3+iPaGcTxKGuiwO9LsTIw==; Date: Mon, 02 Feb 2026 16:21:10 +0200 Message-Id: <86zf5r1b1l.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvzf5rcl5e.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Mon, 02 Feb 2026 09:05:18 -0500) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <86wm0w2ze3.fsf@HIDDEN> <jwva4xsfk0v.fsf-monnier+emacs@HIDDEN> <86ms1s2qjw.fsf@HIDDEN> <jwvpl6oukft.fsf-monnier+emacs@HIDDEN> <867bsv2rob.fsf@HIDDEN> <jwvzf5rcl5e.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN > Date: Mon, 02 Feb 2026 09:05:18 -0500 > > >> > When the implementation (and the restrictions it comes with) are taken > >> > into account, your original program had a definite deadlock. > >> [ But that basically means you're defining the behavior from the > >> implementation, which seems backward. ] > > We are not designing Emacs, are we? > > When it comes to bug-reports, the first thing we need to do is > decide whether it's actually a bug (i.e. a behavior which we'd > ideally want to change) or a feature (i.e. a behavior we'd ideally want > to keep). > > This should not be based on the constraints of the current implementation. Up to a point. If the basic design comes with some restrictions, it is not useful to talk about behavior which needs these restrictions lifted, unless the goal is to redesign and reimplement. IOW, this is a difference between a bug and a missing feature. > So, please could we start by establishing whether you agree that what > I'm asking would be desirable (when considered regardless of > implementation)? Desirable? maybe. But is it possible in Emacs? I'm not sure. > > That will not fit your bill, I think, because -- yes -- how this stuff > > is implemented. A timeout of 1 day means that accept-process-output > > might wait for a full day before doing anything (in practice, I think > > we never wait more than 60 or 90 sec, but that's sheer luck). > > Do you mean that with a 1-day timeout, accept-process-output may run > a timer upto 60s later than the time at which it's supposed to run or run > a sentinel upto 60s after the process exited? No, I mean accept-process-output could wait in pselect for 1 day. Whereas what you want is for it to loop inside wait_reading_process_output and running timers.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 2 Feb 2026 14:05:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 02 09:05:29 2026 Received: from localhost ([127.0.0.1]:57098 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vmuYT-0004RI-63 for submit <at> debbugs.gnu.org; Mon, 02 Feb 2026 09:05:29 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:24634) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vmuYR-0004Qb-B3 for 80286 <at> debbugs.gnu.org; Mon, 02 Feb 2026 09:05:27 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A738010013E; Mon, 2 Feb 2026 09:05:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1770041120; bh=siF2lePuiYH+KkBKQSCh26muusnrI8N3QPmciANrFN8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=TIAAgryiCUrJAM9LeAFYqbiT1tf2irRnuYFeS6BXKGcUVO0m62wwBJ1IpI2RVsQLQ OmVOs96tEnyIYIs+Sf4+XBrAjQfl8OIrLUouyo+yu+m6jsm22/Z6FbzkPP0e29hXw9 e7c8OzRgLKh3sZrd3coe0k/uZYHsA08fkondZPnV2Qpuz1UZawbKN/23j/KDcdr2GM FMqlRuQ3BNIm1WCa20h55o2rX2XvdLY39JZmHO1ZnOYgV5SJURWrXIvWs8vouw69r8 QKNiC95kZ2GHOdxsjbg2yjhRUKAy2vHE5r0qFTOKlKcT0XqsKlyiVvJa4EzG0YePgZ HjGpTWATQAh5w== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9BC0B10002E; Mon, 2 Feb 2026 09:05:20 -0500 (EST) Received: from pastel (104-195-243-38.cpe.teksavvy.com [104.195.243.38]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 68312120437; Mon, 2 Feb 2026 09:05:20 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers In-Reply-To: <867bsv2rob.fsf@HIDDEN> Message-ID: <jwvzf5rcl5e.fsf-monnier+emacs@HIDDEN> References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <86wm0w2ze3.fsf@HIDDEN> <jwva4xsfk0v.fsf-monnier+emacs@HIDDEN> <86ms1s2qjw.fsf@HIDDEN> <jwvpl6oukft.fsf-monnier+emacs@HIDDEN> <867bsv2rob.fsf@HIDDEN> Date: Mon, 02 Feb 2026 09:05:18 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.185 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) >> No, I'm quite aware of the reality. The mental model I have is of how >> timers should behave, taken from the way they behave is non-Emacs >> contexts where they're just interrupts/signals. > > You may remember that originally timers in Emacs worked by running an > external program which would deliver SIGALRM to Emacs, and then the > timer would run from the signal handler. Then Morten Welinder > implemented what we have now in Emacs 19, and the rest is the > proverbial history. I know, but that's irrelevant because I'm talking about the Lisp semantics, not its implementation. >> > When the implementation (and the restrictions it comes with) are taken >> > into account, your original program had a definite deadlock. >> [ But that basically means you're defining the behavior from the >> implementation, which seems backward. ] > We are not designing Emacs, are we? When it comes to bug-reports, the first thing we need to do is decide whether it's actually a bug (i.e. a behavior which we'd ideally want to change) or a feature (i.e. a behavior we'd ideally want to keep). This should not be based on the constraints of the current implementation. > We are talking about existing features, whose behavior is a de-facto > standard. You are asking questions and report bugs about those > existing features, and I thought that useful answers should consider > the fundamental traits of the implementation, because that's the only > firm basis we have to talk about this. But if you start your thought process with "can this be done", the answer will all too often be "no" and the bug-reporter may feel very frustrated because you seem to be saying that what he wants is not desirable, whereas in reality you're just saying that you can't see how to provide it. So, please could we start by establishing whether you agree that what I'm asking would be desirable (when considered regardless of implementation)? IOW, I'm asking whether you'd want to close this bug as WONTFIX or as NOTABUG. > If we decide to talk based on some hypothetical and very different > implementation, we should first define it (and do so in a way that > would make their implementation possible in Emacs), or else we will > talk past each other, each one with his own personal vision of that. I have no idea how to implement it, and haven't really spent time thinking about it because from the exchange we'd had so far I get the impression you'd consider it a misfeature, which I simply can't understand. > That will not fit your bill, I think, because -- yes -- how this stuff > is implemented. A timeout of 1 day means that accept-process-output > might wait for a full day before doing anything (in practice, I think > we never wait more than 60 or 90 sec, but that's sheer luck). Do you mean that with a 1-day timeout, accept-process-output may run a timer upto 60s later than the time at which it's supposed to run or run a sentinel upto 60s after the process exited? Really? I've never experienced such problems. Do we document this limitation somewhere? >> I'm talking about Lisp-level interrupts (which we don't quite have but >> which timers, filters, and sentinels approximate fairly well), not >> C-level interrupts. > AFAIU your complaints, they actually do NOT approximate interrupts > well enough for you, because you are unhappy with what they give you. That's right. =F0=9F=99=82 =3D=3D=3D Stefan
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 2 Feb 2026 14:01:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 02 09:01:09 2026 Received: from localhost ([127.0.0.1]:57026 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vmuUH-00047X-HS for submit <at> debbugs.gnu.org; Mon, 02 Feb 2026 09:01:09 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59270) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vmuUF-000473-2I for 80286 <at> debbugs.gnu.org; Mon, 02 Feb 2026 09:01:07 -0500 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 <eliz@HIDDEN>) id 1vmuU8-0008F4-QB; Mon, 02 Feb 2026 09:01:00 -0500 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=fenb0d2YEajf5OOodkYafUV61IzuywDnFosa16SPCVs=; b=Qhr47odT9B2M iMpap53H0NVawwcw0ndeS3pmo2rRm3OXwJ5hGVdVe6PNkQ81K3n/8yOsCSSOmKGhoQV1UGPJNPKmc tAGV5BTTu3N3DBUXV61rkDrckWYS2erNyme27ScRaTLXuU8oVTzP7Lv6+j1NVcxpxwtyIOXG8xbAo bWwMnIQjlTcof70AGIPsfPNurC/CU1/uCOE1v1AIK/os8eGgyw6epzF0v2oT3odE5l61grQDwNd9u 8iTq/qOEDBx8himtv0M1QTbWZ88ix69R1l3NvLaWolbl2U2JSDss7e8esvpcoxoE0Q56L1+8FyLV/ iI2R2D0SaF55f2+gg6n+IA==; Date: Mon, 02 Feb 2026 16:00:56 +0200 Message-Id: <86343j2qjr.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvms1ret7j.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sun, 01 Feb 2026 22:13:18 -0500) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86zf5t4smf.fsf@HIDDEN> <jwvy0lcfqca.fsf-monnier+emacs@HIDDEN> <86y0lc31c7.fsf@HIDDEN> <jwvms1sfng2.fsf-monnier+emacs@HIDDEN> <86qzr42rzj.fsf@HIDDEN> <jwvms1ret7j.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN > Date: Sun, 01 Feb 2026 22:13:18 -0500 > > >> IOW, I think the test below should succeed, yet it fails (well, the > >> reality seems more complex: when I test it in this Gnus session, it > >> sometimes succeeds (the probability seems related to the 0.5 argument), > >> but in batch or in a fresh new session it seems to fail reliably). > > > > In your example, the non-main thread is stuck in pselect for 2 sec, > > and C-g doesn't work when Emacs is in a syscall. So I don't think I > > understand your expectations. > > Before we look at the implementation, I want to discuss the intended > behavior, i.e. based on the documented behavior of the functions, do you > think the implementation should better try to make sure the test > succeeds, or try to make sure it fails? Ok, but which behavior would you like to discuss? Is it the behavior of accept-process-output, or the effect of thread-signal on accept-process-output, or what condition-wait does, or how timers are run, or something else? If this is about thread-signal, then I could argue that it already behaves like C-g: you cannot interrupt certain syscalls.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 2 Feb 2026 13:36:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 02 08:36:46 2026 Received: from localhost ([127.0.0.1]:56698 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vmu6f-0002Vf-HN for submit <at> debbugs.gnu.org; Mon, 02 Feb 2026 08:36:46 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57126) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vmu6e-0002VS-1J for 80286 <at> debbugs.gnu.org; Mon, 02 Feb 2026 08:36:44 -0500 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 <eliz@HIDDEN>) id 1vmu6Y-0003Cw-3E; Mon, 02 Feb 2026 08:36:38 -0500 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=YGORxGOzdQg9H1VAtawGz+XMHYFk0SJ9KqLTQstzWb8=; b=mTkWKk21rTv/ rDVhORT5y+OOBekg85ojeVYonQYw05kLA/QE49nIcXdWIO37R/XPY0399hvgpsv8sBvm1MqiwQ7b5 EiEosh7VMDYMjzYLiSsVyK2BJjtsdjZzYyy3MSnF7UecuG38FNrGOaihwjX71BEvp0/Hp/UfJoUYe hnqUoR/ZNCgpPzqiZoRszUdSxY8AYqXqfgOwwaf7Ah0eX/er8V8dvvFNxtcwc446b87oE8/N0KsUq 9ZHuFSZt6rHZ8bLQDddF9jkV1ruxeUSKjEpdnXNo7hIO1QvLAXi7L26fNuT+Yf2XT7Lhvt0Rzrlk/ 1W2idSGlGawkdg6DCXuBRw==; Date: Mon, 02 Feb 2026 15:36:36 +0200 Message-Id: <867bsv2rob.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvpl6oukft.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sun, 01 Feb 2026 18:22:27 -0500) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <86wm0w2ze3.fsf@HIDDEN> <jwva4xsfk0v.fsf-monnier+emacs@HIDDEN> <86ms1s2qjw.fsf@HIDDEN> <jwvpl6oukft.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN > Date: Sun, 01 Feb 2026 18:22:27 -0500 > > >> I disagree with the description of my problem as a "deadlock": the way > >> I see it, the problem is not that I want to break the deadlock, it's > >> that it shouldn't be a deadlock in the first place. > > I think that's because you have a certain mental model of how timers > > are implemented that doesn't necessarily match the reality. > > No, I'm quite aware of the reality. The mental model I have is of how > timers should behave, taken from the way they behave is non-Emacs > contexts where they're just interrupts/signals. You may remember that originally timers in Emacs worked by running an external program which would deliver SIGALRM to Emacs, and then the timer would run from the signal handler. Then Morten Welinder implemented what we have now in Emacs 19, and the rest is the proverbial history. > > When the implementation (and the restrictions it comes with) are taken > > into account, your original program had a definite deadlock. > > [ But that basically means you're defining the behavior from the > implementation, which seems backward. ] We are not designing Emacs, are we? We are talking about existing features, whose behavior is a de-facto standard. You are asking questions and report bugs about those existing features, and I thought that useful answers should consider the fundamental traits of the implementation, because that's the only firm basis we have to talk about this. If we decide to talk based on some hypothetical and very different implementation, we should first define it (and do so in a way that would make their implementation possible in Emacs), or else we will talk past each other, each one with his own personal vision of that. > >> > I'm also not sure we will know what code to run in > >> > the thread. For example, the value 20 you used depends on what the > >> > rest of the program does, but how to select it in general? > >> There should be no timeout, really, all that "thread" ever needs to do > >> is run the interrupts. > > If you mean much smaller timeout values, that would make the thread > > busy-wait and waste cycles and battery. So clearly, "no timeout" is > > not the best solution. > > "no timeout" in the sense that the "special thread" never needs to > return from `accept-process-output`. > In my tests, I use a timeout of 1 day, which together with a `while t` > gives me a "good enough" approximation. That will not fit your bill, I think, because -- yes -- how this stuff is implemented. A timeout of 1 day means that accept-process-output might wait for a full day before doing anything (in practice, I think we never wait more than 60 or 90 sec, but that's sheer luck). > >> >> It doesn't do it itself: the thing it's waiting for will be done by > >> >> something else which runs asynchronously (a timer, a process sentinel). > >> >> It's just that currently, when that async "signal/interrupt" shows up, > >> >> Emacs insists on running the handler in one of the existing threads. > >> > Where else can it run them? > >> In the interrupt handler context, of course. > >> This usually doesn't belong to any thread. > > There are no interrupts in Emacs, not nowadays. We had them once, but > > no more, because we decided that running Lisp from an interrupt > > handler is more trouble than the gains it gives us. > > I'm talking about Lisp-level interrupts (which we don't quite have but > which timers, filters, and sentinels approximate fairly well), not > C-level interrupts. AFAIU your complaints, they actually do NOT approximate interrupts well enough for you, because you are unhappy with what they give you.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 2 Feb 2026 03:13:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 01 22:13:31 2026 Received: from localhost ([127.0.0.1]:49126 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vmkNX-0004mm-1F for submit <at> debbugs.gnu.org; Sun, 01 Feb 2026 22:13:31 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18710) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vmkNS-0004lh-D6 for 80286 <at> debbugs.gnu.org; Sun, 01 Feb 2026 22:13:29 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 73FB41000BC; Sun, 1 Feb 2026 22:13:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1770001999; bh=dB5TJwNrV0iDOtnIblBv4iejfoLrUl62BJrPFiohKzc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hVI63C8sOFBCb8yq4Bsd3uWPMfUj6D6vMOp935MV5p1qEBHOYi3ppwxduOMj/M3C+ m5c+u6RpuSuOPbLI6NppAm7cpSPLJqrY2ojoe3oyU1evjvJ7dS8N0cvssm0V8mqrLt vHYqjUH2yrQPyYSI2uCoi6+uEq60FiW36D0zMQu3cBxp5VGlCCejXEH9IZj9IsKtOW 9KiNrByfE0mMoFA7TdWEpXvtH4S7ktTTMRMxdrGaSFvkJ9XMPrAdy0VPrWCf1Suzke O1yNDJVxhPfJx/zGrsg6k8cgAObHOnXiZAtt2ubRV9Lq7FzTl6yV3SgVV7uJqKFtER EacIiJu6SW4xg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A05A810002D; Sun, 1 Feb 2026 22:13:19 -0500 (EST) Received: from pastel (104-195-243-38.cpe.teksavvy.com [104.195.243.38]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6F6FC120661; Sun, 1 Feb 2026 22:13:19 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers In-Reply-To: <86qzr42rzj.fsf@HIDDEN> Message-ID: <jwvms1ret7j.fsf-monnier+emacs@HIDDEN> References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86zf5t4smf.fsf@HIDDEN> <jwvy0lcfqca.fsf-monnier+emacs@HIDDEN> <86y0lc31c7.fsf@HIDDEN> <jwvms1sfng2.fsf-monnier+emacs@HIDDEN> <86qzr42rzj.fsf@HIDDEN> Date: Sun, 01 Feb 2026 22:13:18 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.176 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) >> IOW, I think the test below should succeed, yet it fails (well, the >> reality seems more complex: when I test it in this Gnus session, it >> sometimes succeeds (the probability seems related to the 0.5 argument), >> but in batch or in a fresh new session it seems to fail reliably). > > In your example, the non-main thread is stuck in pselect for 2 sec, > and C-g doesn't work when Emacs is in a syscall. So I don't think I > understand your expectations. Before we look at the implementation, I want to discuss the intended behavior, i.e. based on the documented behavior of the functions, do you think the implementation should better try to make sure the test succeeds, or try to make sure it fails? === Stefan
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 1 Feb 2026 23:22:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 01 18:22:43 2026 Received: from localhost ([127.0.0.1]:46580 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vmgm8-00030s-9p for submit <at> debbugs.gnu.org; Sun, 01 Feb 2026 18:22:43 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:22785) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vmgm3-0002zi-Px for 80286 <at> debbugs.gnu.org; Sun, 01 Feb 2026 18:22:38 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D2BF881C62; Sun, 1 Feb 2026 18:22:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1769988148; bh=1RfvjoWtAP/LjGnm3tqIhkL+iMdIIYfIARKmPqN6tAA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZKc28EBgqQWZzYOzvQ/KsYvqX7G5h/HYKMtVB1UgKMyvMzu1U8ZA+RvTIEM/UP0fw g2R082wh9Ie5cXi8rHRzOAgMxGxCEqd2TS5kzhKKEA7hWXuH5MNZW7IJm+PsNc+cVX TfKIYlXydIT9aWN2k00G3wbjwW+bhz3u2sEuUX8wqGMNT56FWeJbfe8CZ6lcUSUYth V9vstz2biaoUhmc0koHoTKgA8y2vv2VyatLdrea59ld37u1SjSKVxE5rISmJPm31mk WYD9QVOHqe5Z9PkhwKI1WszW4jm/p4/Bg9kIHqWetaKDOl1HL8W/tu8v2uFpQTIOV+ kAZ8dXWFqHJ7Q== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id BF5AD816A5; Sun, 1 Feb 2026 18:22:28 -0500 (EST) Received: from alfajor (104-195-243-38.cpe.teksavvy.com [104.195.243.38]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 80A8A120627; Sun, 1 Feb 2026 18:22:28 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers In-Reply-To: <86ms1s2qjw.fsf@HIDDEN> Message-ID: <jwvpl6oukft.fsf-monnier+emacs@HIDDEN> References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <86wm0w2ze3.fsf@HIDDEN> <jwva4xsfk0v.fsf-monnier+emacs@HIDDEN> <86ms1s2qjw.fsf@HIDDEN> Date: Sun, 01 Feb 2026 18:22:27 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.139 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) >> I disagree with the description of my problem as a "deadlock": the way >> I see it, the problem is not that I want to break the deadlock, it's >> that it shouldn't be a deadlock in the first place. > I think that's because you have a certain mental model of how timers > are implemented that doesn't necessarily match the reality. No, I'm quite aware of the reality. The mental model I have is of how timers should behave, taken from the way they behave is non-Emacs contexts where they're just interrupts/signals. > When the implementation (and the restrictions it comes with) are taken > into account, your original program had a definite deadlock. [ But that basically means you're defining the behavior from the implementation, which seems backward. ] >> I don't really need/want to start a new thread. I just need Emacs to >> run its interrupts (aka timers, filters, sentinels, ...) eventually. > Since Emacs is a single-threaded program, this doesn't really work, > except in some very specific cases. I think what you're trying to tell me is that you don't know how to fix it without a large rewrite with unforeseeable effects. I would accept that. But instead you're telling me that the current behavior is what we want, which I can't agree with. >> > I'm also not sure we will know what code to run in >> > the thread. For example, the value 20 you used depends on what the >> > rest of the program does, but how to select it in general? >> There should be no timeout, really, all that "thread" ever needs to do >> is run the interrupts. > If you mean much smaller timeout values, that would make the thread > busy-wait and waste cycles and battery. So clearly, "no timeout" is > not the best solution. "no timeout" in the sense that the "special thread" never needs to return from `accept-process-output`. In my tests, I use a timeout of 1 day, which together with a `while t` gives me a "good enough" approximation. >> >> It doesn't do it itself: the thing it's waiting for will be done by >> >> something else which runs asynchronously (a timer, a process sentinel). >> >> It's just that currently, when that async "signal/interrupt" shows up, >> >> Emacs insists on running the handler in one of the existing threads. >> > Where else can it run them? >> In the interrupt handler context, of course. >> This usually doesn't belong to any thread. > There are no interrupts in Emacs, not nowadays. We had them once, but > no more, because we decided that running Lisp from an interrupt > handler is more trouble than the gains it gives us. I'm talking about Lisp-level interrupts (which we don't quite have but which timers, filters, and sentinels approximate fairly well), not C-level interrupts. === Stefan
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 1 Feb 2026 19:48:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 01 14:48:46 2026 Received: from localhost ([127.0.0.1]:43840 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vmdR7-0000YL-P7 for submit <at> debbugs.gnu.org; Sun, 01 Feb 2026 14:48:46 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52806) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vmdR5-0000XY-5B for 80286 <at> debbugs.gnu.org; Sun, 01 Feb 2026 14:48:43 -0500 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 <eliz@HIDDEN>) id 1vmdQz-0004Bd-K6; Sun, 01 Feb 2026 14:48:37 -0500 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=lAMRbs3ux2HK29u3p8QT1chUXxqdVxxnDPHWGZrvb4M=; b=UT8MP+2IZNHy SpsZZhwmlPeTqut3dcCYa4T4fz+r2/qLa61Ki+UQRecRWz5reeHPbHBQayXQ+6OeVVK/vnZB9hoRG N+eCGJ510bxWOCWuYSDCsgel+mrTH8E5bkrRBCmc1gEX11692wUzVGN7oNI1KpEzRJtvZF9POYKE2 W37nhjg5lbmgH0JFqFnnD9zFV+FysJd8pDXbd92+m4GEJKoj9EtRlQPxSOk/dbU/LNj2kUevJEuvW aKpydkLLN3V2Mj/8vqSBpS38QgJaytoBOvrGNb22odBqZimO0Ol3Li1+1wiw0hTLZ3LgvZpC0TIcz ncYMGS8+E6nhaMwHUXZ1DA==; Date: Sun, 01 Feb 2026 21:48:35 +0200 Message-Id: <86ms1s2qjw.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwva4xsfk0v.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sun, 01 Feb 2026 12:50:00 -0500) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <86wm0w2ze3.fsf@HIDDEN> <jwva4xsfk0v.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN > Date: Sun, 01 Feb 2026 12:50:00 -0500 > > >> >> That'd be very unusual and unexpected, I think. > >> Timers/filters/sentinels are the closest thing ELisp has to hardware > >> interrupts. These don't run in any specific thread. > >> So I disagree with "unusual" and "unexpected". > > What other software do you know that starts threads like this when > > there could be deadlock? > > I disagree with the description of my problem as a "deadlock": the way > I see it, the problem is not that I want to break the deadlock, it's > that it shouldn't be a deadlock in the first place. I think that's because you have a certain mental model of how timers are implemented that doesn't necessarily match the reality. When the implementation (and the restrictions it comes with) are taken into account, your original program had a definite deadlock. > I don't really need/want to start a new thread. I just need Emacs to > run its interrupts (aka timers, filters, sentinels, ...) eventually. Since Emacs is a single-threaded program, this doesn't really work, except in some very specific cases. > > I'm also not sure we will know what code to run in > > the thread. For example, the value 20 you used depends on what the > > rest of the program does, but how to select it in general? > > There should be no timeout, really, all that "thread" ever needs to do > is run the interrupts. If you mean much smaller timeout values, that would make the thread busy-wait and waste cycles and battery. So clearly, "no timeout" is not the best solution. > >> It doesn't do it itself: the thing it's waiting for will be done by > >> something else which runs asynchronously (a timer, a process sentinel). > >> It's just that currently, when that async "signal/interrupt" shows up, > >> Emacs insists on running the handler in one of the existing threads. > > Where else can it run them? > > In the interrupt handler context, of course. > This usually doesn't belong to any thread. There are no interrupts in Emacs, not nowadays. We had them once, but no more, because we decided that running Lisp from an interrupt handler is more trouble than the gains it gives us.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 1 Feb 2026 19:17:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 01 14:17:47 2026 Received: from localhost ([127.0.0.1]:43475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vmcx9-0006Cx-Cd for submit <at> debbugs.gnu.org; Sun, 01 Feb 2026 14:17:47 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50492) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vmcx6-0006Cg-OI for 80286 <at> debbugs.gnu.org; Sun, 01 Feb 2026 14:17:45 -0500 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 <eliz@HIDDEN>) id 1vmcx1-0005Dn-3N; Sun, 01 Feb 2026 14:17:39 -0500 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=IJitcio9TaT6ahng2VU0Ti1oMreKFpRrCk80CXGRG9g=; b=mEOOuBZzOp5o S8wNWagsbRCJY1sADwhxsiyNudsYujutK+tLwimmasIpFKWE6Zh1lg47SVVAkLJPXtCU5Ix7w4SKv 82CmqDgs/WBRz9hqDZbzD0bFhNjkkVnrGYr13/r8wsLoF06JKFf1GdDVJJ9CMf7NBqRPUv2cz+bJH Qb4hMh4YajSUdBLTIIbvRMvjkHK370X90LQeteB+/0knFsU4LE1aSrS0d09sBiP4rzAZsa/CGhaPU 4QMnFwPn/6C+rvQJtdR6axnyPAhS9pm4qEILoQGcuk/BcIye8xp3AxTxoQywbYJOCVjwfTpZIUA2q /nAXGV5OCVM9Ym7sB8PtSg==; Date: Sun, 01 Feb 2026 21:17:36 +0200 Message-Id: <86qzr42rzj.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvms1sfng2.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sun, 01 Feb 2026 12:25:32 -0500) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86zf5t4smf.fsf@HIDDEN> <jwvy0lcfqca.fsf-monnier+emacs@HIDDEN> <86y0lc31c7.fsf@HIDDEN> <jwvms1sfng2.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN > Date: Sun, 01 Feb 2026 12:25:32 -0500 > > >> Ah, yes, indeed that's another problem. I can't find an existing > >> bug-number for this (i.e. for the fact that `thread-signal` does not > >> interrupt an `accept-process-output`), tho. > >> Is my search-fu weak? > > > > It's bug#78773 and this discussion: > > > > https://lists.gnu.org/archive/html/emacs-devel/2025-08/msg00750.html > > Ah, that's what you meant. > > Well, maybe it's "the same" in terms of implementation but I think the > argument is a bit different for `thread-signal`: one can argue whether > the TIMEOUT argument is meant as a minimum or maximum in different > circumstances, but I believe it is more clear that a signal *should* > cause an early exit from `accept-process-output`, just like `C-g` > already does. > > IOW, I think the test below should succeed, yet it fails (well, the > reality seems more complex: when I test it in this Gnus session, it > sometimes succeeds (the probability seems related to the 0.5 argument), > but in batch or in a fresh new session it seems to fail reliably). In your example, the non-main thread is stuck in pselect for 2 sec, and C-g doesn't work when Emacs is in a syscall. So I don't think I understand your expectations. In a session which runs Gnus, I'm guessing you have timers that break the 2-sec wait into shorter periods, so the thread does several shorter waits, and thus has opportunities to check for the signal.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 1 Feb 2026 17:50:11 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 01 12:50:11 2026 Received: from localhost ([127.0.0.1]:42481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vmbaM-0006si-Mr for submit <at> debbugs.gnu.org; Sun, 01 Feb 2026 12:50:11 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23767) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vmbaK-0006o1-9v for 80286 <at> debbugs.gnu.org; Sun, 01 Feb 2026 12:50:08 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id DCF161000BC; Sun, 1 Feb 2026 12:50:02 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1769968201; bh=ld0eTwyQdknUVjO+mVLrz0wxq+J3f1yrOAWYjvsRP3E=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QcDWjKfEu57QVzGRjwYeelmxr+k2Kxv43FOY+1fKhaYtB9apbpuUyAW6DYSeL6xPO 1LkqkERxAZ64QRTGpNxSCIB3EjS8IxsXms3L/oiYSkkK188Hzk/AYzwLJJiuk6PcuY 1vdVR4G14Xhf2cU+T0uZ8nJGNlUKaUI2FdVrWWBVszorc7q7KfNBLnt2RvMIjm8krI c10BgjbFPH/Po8r+1KaB4RXIaOD8Oy78PCgGW6Do8SEV9M+SyAcArmT+kJm0kYbbwY j/tFa42J9NhJIblemy56unV2J76TrbmThauKi6PjFzGgLYHsa2sK6VfnWjWyfeTof5 hLys1DgfaCj7g== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C742210002D; Sun, 1 Feb 2026 12:50:01 -0500 (EST) Received: from pastel (104-195-243-38.cpe.teksavvy.com [104.195.243.38]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 94DA31208DF; Sun, 1 Feb 2026 12:50:01 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers In-Reply-To: <86wm0w2ze3.fsf@HIDDEN> Message-ID: <jwva4xsfk0v.fsf-monnier+emacs@HIDDEN> References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> <86wm0w2ze3.fsf@HIDDEN> Date: Sun, 01 Feb 2026 12:50:00 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.179 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) >> >> That'd be very unusual and unexpected, I think. >> Timers/filters/sentinels are the closest thing ELisp has to hardware >> interrupts. These don't run in any specific thread. >> So I disagree with "unusual" and "unexpected". > What other software do you know that starts threads like this when > there could be deadlock? I disagree with the description of my problem as a "deadlock": the way I see it, the problem is not that I want to break the deadlock, it's that it shouldn't be a deadlock in the first place. I don't really need/want to start a new thread. I just need Emacs to run its interrupts (aka timers, filters, sentinels, ...) eventually. > We could document that if these situations could happen in a Lisp > program, that program should make sure some thread will be available > to run the timers, and even give an example. FWIW, I still don't know how to make sure some thread will be available. The `make-thread` hack I used so far is not reliable: its `accept-process-output` might itself run an interrupt that ends up blocking the thread. I believe my future/promise code is careful not to do that (because indeed that seems like a very bad idea: it's well known that interrupt handlers should be careful not to take locks or do anything that could block). But `accept-process-output` will run any and all filters/timers/... rather than only those I wrote, so there's still a possibility. > I'm also not sure we will know what code to run in > the thread. For example, the value 20 you used depends on what the > rest of the program does, but how to select it in general? There should be no timeout, really, all that "thread" ever needs to do is run the interrupts. >> It doesn't do it itself: the thing it's waiting for will be done by >> something else which runs asynchronously (a timer, a process sentinel). >> It's just that currently, when that async "signal/interrupt" shows up, >> Emacs insists on running the handler in one of the existing threads. > Where else can it run them? In the interrupt handler context, of course. This usually doesn't belong to any thread. > So maybe we have problems that are hard to solve in Emacs, and some of > those solutions might require extra threads to be started. > But I still don't see why these cases would be frequent enough to make > such a significant change in the infrastructure. Even if the problem > of what and how exactly to run in that thread could be solved in > general in some satisfactory way. FWIW, my code still doesn't work satisfactorily with that `make-thread` workaround, but I haven't figured out exactly why yet. === Stefan
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.
Received: (at 80286) by debbugs.gnu.org; 1 Feb 2026 17:25:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 01 12:25:49 2026
Received: from localhost ([127.0.0.1]:42140 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vmbCn-0004gS-A9
for submit <at> debbugs.gnu.org; Sun, 01 Feb 2026 12:25:49 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:35759)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vmbCl-0004g4-L0
for 80286 <at> debbugs.gnu.org; Sun, 01 Feb 2026 12:25:48 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 789A0440BB1;
Sun, 1 Feb 2026 12:25:41 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1769966739;
bh=PPPNc72FY2pPdKQKvPVfOBtI2FDng2Z4TrmNNp33y0s=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=Tflljag8iZdHrvW64gkmKXqkG/tdbNolOrLcv9igPaDQHD0ZPvyseRnEUJjTgFevh
H5sehoN77+lhGzhxrT96LxxhB/KrdLBtBPq0IPrOIKPoZrK9stILIBWr+ovaBDQ+Pi
yULHACvaFmQotWF0OUHNiHp3WAJpn5IUxZjT+imOeE8ClgsJaogTGKp/dQrXCrRRhl
AjGE4Kgl5DSPjmx5ws/KOnYBUBgmQpY3hK1Dj64fTlUQeTZY4we3yBPeYrHbX2/Tap
owUTuBvFPLSSf0OlWK9Uj3BX+gLx8AD1OHvvwkaC1Y9fv9AuarasEWePuvwjrG49Wp
8nCF/H06iY4pg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A83CD440B14;
Sun, 1 Feb 2026 12:25:39 -0500 (EST)
Received: from pastel (104-195-243-38.cpe.teksavvy.com [104.195.243.38])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7DC021208C9;
Sun, 1 Feb 2026 12:25:39 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers
In-Reply-To: <86y0lc31c7.fsf@HIDDEN>
Message-ID: <jwvms1sfng2.fsf-monnier+emacs@HIDDEN>
References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN>
<jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86zf5t4smf.fsf@HIDDEN>
<jwvy0lcfqca.fsf-monnier+emacs@HIDDEN> <86y0lc31c7.fsf@HIDDEN>
Date: Sun, 01 Feb 2026 12:25:32 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.217 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80286
Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> Ah, yes, indeed that's another problem. I can't find an existing
>> bug-number for this (i.e. for the fact that `thread-signal` does not
>> interrupt an `accept-process-output`), tho.
>> Is my search-fu weak?
>
> It's bug#78773 and this discussion:
>
> https://lists.gnu.org/archive/html/emacs-devel/2025-08/msg00750.html
Ah, that's what you meant.
Well, maybe it's "the same" in terms of implementation but I think the
argument is a bit different for `thread-signal`: one can argue whether
the TIMEOUT argument is meant as a minimum or maximum in different
circumstances, but I believe it is more clear that a signal *should*
cause an early exit from `accept-process-output`, just like `C-g`
already does.
IOW, I think the test below should succeed, yet it fails (well, the
reality seems more complex: when I test it in this Gnus session, it
sometimes succeeds (the probability seems related to the 0.5 argument),
but in batch or in a fresh new session it seems to fail reliably).
=== Stefan
(ert-deftest thread-signal-accept-process-output ()
(let* ((start-time (float-time))
(thread-started nil)
(thread-completed nil)
(idle-loop
(make-thread (lambda ()
(setq thread-started t)
(unwind-protect
(while t (accept-process-output nil 2.0))
(setq thread-completed t)
(should (< (- (float-time) start-time) 1.0)))))))
(accept-process-output nil 0.01) ;; Let the thread start.
(should thread-started)
(thread-signal idle-loop 'error '("foo"))
(accept-process-output nil 0.5) ;; Give ample time to react to the signal.
(should (< 0.4 (- (float-time) start-time) 1.1))
(should thread-completed)
(should (not (thread-live-p idle-loop)))))
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 1 Feb 2026 16:37:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 01 11:37:55 2026 Received: from localhost ([127.0.0.1]:41553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vmaSR-0000Y2-0E for submit <at> debbugs.gnu.org; Sun, 01 Feb 2026 11:37:55 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60974) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vmaSL-0000Xi-Ua for 80286 <at> debbugs.gnu.org; Sun, 01 Feb 2026 11:37:52 -0500 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 <eliz@HIDDEN>) id 1vmaSF-0000EZ-OE; Sun, 01 Feb 2026 11:37:43 -0500 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=Rm11QnU6e0lEqTDL2OEP2DfAJ3rEmgZlIAdG9LhazkY=; b=RxS7zP3b39dg 2IflGCBp/tOn3G3lruBnuO76wj7Su723Zi1Dr+sYO2KBQ2WjvI5+D+6kNS6PZGAP079UhT5X+mtmd UFMv+rxoA623AeCrJSAKvBfws73QH3hNZgqHXUdp/4d5bEo8QcXbaQK33Wj1z6Wmije7LPmnvhFGv gJI2SJX8zCv1GAo1g911AY+DUZYIz89kcbKPGNmDdWrpl82yJZJjjjviGAZxyuRyvv8oGM57fo5jA FpZxmue/mPQzkw/osKK2zfduquDM0LSka6yFpSKjly0qnAgbtz93zSweHxNodCaeeEisyR6gv7T+P TVBthOQ4wfoBucVBiXOmcQ==; Date: Sun, 01 Feb 2026 18:37:40 +0200 Message-Id: <86wm0w2ze3.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sun, 01 Feb 2026 10:14:38 -0500) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN> <jwv4io0h63j.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN > Date: Sun, 01 Feb 2026 10:14:38 -0500 > > >> > > Btw, we could perhaps detect the situation where condition-wait is > >> > > called when there's only one thread in the list of threads, and signal > >> > > an error in that case, which would prevent the deadlock. But somehow > >> > > my impression was that this is not the solution you are looking for. > >> > Rather than signal an error, it could spawn a thread that > >> > does `accept-process-output`. > >> That'd be very unusual and unexpected, I think. > > Timers/filters/sentinels are the closest thing ELisp has to hardware > interrupts. These don't run in any specific thread. > So I disagree with "unusual" and "unexpected". What other software do you know that starts threads like this when there could be deadlock? We could document that if these situations could happen in a Lisp program, that program should make sure some thread will be available to run the timers, and even give an example. But starting a Lisp thread on our own, just because we decided it might be needed sounds too much to me. I'm also not sure we will know what code to run in the thread. For example, the value 20 you used depends on what the rest of the program does, but how to select it in general? > > Let me turn the table ask: why would the main thread use > > condition-wait to wait for something it itself does? > > It doesn't do it itself: the thing it's waiting for will be done by > something else which runs asynchronously (a timer, a process sentinel). > It's just that currently, when that async "signal/interrupt" shows up, > Emacs insists on running the handler in one of the existing threads. Where else can it run them? > The concrete use-case where it showed up is > `futur-blocking-wait-to-get-result` (below, excerpted from > a WiP future/promise package). > > As you can see, I do have an alternative implementation that uses those > "simpler ways" (called `futur-blocker-wait`), but: > > - It's much less simple than the "obvious" alternative of letting the > future/promise call `condition-notify` when it's done. > - It does not wake up right away because we have to add extra waits > where we don't really know what to wait for, so we have to use > a busy-wait loop with an arbitrary timeout. > - It's less efficient because of that busy-wait loop. > > So if the timeout in the busy-wait loop is too short, we waste resources > spinning in the loop, and if it's too long, we add extra delays where > Emacs could continue working but sits there waiting for nothing instead. So maybe we have problems that are hard to solve in Emacs, and some of those solutions might require extra threads to be started. But I still don't see why these cases would be frequent enough to make such a significant change in the infrastructure. Even if the problem of what and how exactly to run in that thread could be solved in general in some satisfactory way.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 1 Feb 2026 15:55:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 01 10:55:52 2026 Received: from localhost ([127.0.0.1]:40982 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vmZnk-0005Qw-48 for submit <at> debbugs.gnu.org; Sun, 01 Feb 2026 10:55:52 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40390) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vmZng-0005QD-It for 80286 <at> debbugs.gnu.org; Sun, 01 Feb 2026 10:55:50 -0500 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 <eliz@HIDDEN>) id 1vmZnb-00076W-3X; Sun, 01 Feb 2026 10:55:43 -0500 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=7Qfo66a68mqNInC7oUdKuwsa3Tu0k6UBEiJ+kjwQbec=; b=scgtvFgTMRBT nzpclDG559daRiG/vk/xEd6Ag+8Q++jzTJomQwPiFookH7SIwnBVPfZKnBEJ0mVO6bQZTggZ2VHyX vWsFsVLwA2mJfSIkB4I1JI0+NWeniTeo7nJv56DnwXx29ig4sDkN6Gtt0XLrg3fSAnGAqt/fdC8nu yaw1C2TxCym1ww1iDxc7bUBahqYhPZwfrduaNO8ykNeIpI+Yo8vs0kUCdcqdOAWHMOqUzJF4ul7G2 cil4GT3I855rV9kiDH2NkDFZyDtPuALDAleVuEMfqwjGuJ6IQvxO/q7O3SSYIE0nwXsnX1OLtC/6T /r6Ai2qZCTcczenlpklhaQ==; Date: Sun, 01 Feb 2026 17:55:36 +0200 Message-Id: <86y0lc31c7.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvy0lcfqca.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sun, 01 Feb 2026 10:20:25 -0500) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86zf5t4smf.fsf@HIDDEN> <jwvy0lcfqca.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN > Date: Sun, 01 Feb 2026 10:20:25 -0500 > > > Since ERT runs tests in alphabetic order, your added test runs before > > threads-condvar-wait, and so threads-condvar-wait waits for the > > additional thread to die, which takes 20 sec, as we know from past > > discussions of what accept-process-output does in this case. > > Ah, yes, indeed that's another problem. I can't find an existing > bug-number for this (i.e. for the fact that `thread-signal` does not > interrupt an `accept-process-output`), tho. > Is my search-fu weak? It's bug#78773 and this discussion: https://lists.gnu.org/archive/html/emacs-devel/2025-08/msg00750.html
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 1 Feb 2026 15:20:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 01 10:20:37 2026 Received: from localhost ([127.0.0.1]:40806 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vmZFc-0002SC-KV for submit <at> debbugs.gnu.org; Sun, 01 Feb 2026 10:20:36 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:61145) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vmZFa-0002R4-7F for 80286 <at> debbugs.gnu.org; Sun, 01 Feb 2026 10:20:34 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2E7B91000BC; Sun, 1 Feb 2026 10:20:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1769959227; bh=mUL/QY7hIHyAAeOKEZOZV1h1yjmq7dAn6ZRSF+UW0Rk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bOY95+Z2prfgAyzi0AG3wTcL19wwy7mgxuYt4QjsMQzk7t8YLtzH22uJ/VIt3LoE1 oGDXl8NLxjqlhMFNIPk2fwXoXNkQ8ETp7Re1GcQCT6n5qefyLb/Bux3GluXnDdyGSD QzTmMHqaQvlLGwf81oBPzodv6iFpR5Jz5fnPljwOTXayajWizqZUuTcaUKo31eyUs4 KrSJEa1vZQgnphqzlaBL2O7KLR5+d4cA8G9I1CTxymN9BrMo3VwBJgcnPSEmEJZE7m Hq/eGnA9JuHuqMSigmHYRxWQZeXlCIg+mM2BRiI4/OnmzX/llaBuYyXuUcbRGTMCQe PluKO7sNPGF7g== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 25B3210002D; Sun, 1 Feb 2026 10:20:27 -0500 (EST) Received: from pastel (104-195-243-38.cpe.teksavvy.com [104.195.243.38]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 849AB1208DF; Sun, 1 Feb 2026 10:20:26 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers In-Reply-To: <86zf5t4smf.fsf@HIDDEN> Message-ID: <jwvy0lcfqca.fsf-monnier+emacs@HIDDEN> References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86zf5t4smf.fsf@HIDDEN> Date: Sun, 01 Feb 2026 10:20:25 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.181 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > This is completely unrelated. What waits is one of the following > tests: > > (ert-deftest threads-condvar-wait () > "Test waiting on conditional variable." > (skip-unless (featurep 'threads)) > (let ((cv-mutex (make-mutex)) > new-thread) > ;; We could have spurious threads from the previous tests still > ;; running; wait for them to die. > (while (> (length (all-threads)) 1) <<<<<<<<<<<<<<<< > (thread-yield)) Oh, thanks for the heads up, that's very helpful. > Since ERT runs tests in alphabetic order, your added test runs before > threads-condvar-wait, and so threads-condvar-wait waits for the > additional thread to die, which takes 20 sec, as we know from past > discussions of what accept-process-output does in this case. Ah, yes, indeed that's another problem. I can't find an existing bug-number for this (i.e. for the fact that `thread-signal` does not interrupt an `accept-process-output`), tho. Is my search-fu weak? === Stefan
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.
Received: (at 80286) by debbugs.gnu.org; 1 Feb 2026 15:14:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 01 10:14:50 2026
Received: from localhost ([127.0.0.1]:40779 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vmZA1-0001f5-JI
for submit <at> debbugs.gnu.org; Sun, 01 Feb 2026 10:14:50 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7833)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vmZ9y-0001ei-8G
for 80286 <at> debbugs.gnu.org; Sun, 01 Feb 2026 10:14:47 -0500
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id BCF6C80860;
Sun, 1 Feb 2026 10:14:40 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1769958879;
bh=/68pRb8ltUPNsH2stVM8JF+zCIi08AtgXv849yXntzM=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=HGjXOCDUUFPrRp9t/5lrjHj+snCPslwn6vFvJ3xBTqc8cBmluHHm3m3PVp3Mkga8j
mfvuXfYUf9oJGPWUiLcM2UCYOeTDTWvXpmDHwz6gVrZ3HP9Etg8ShBK1puKH4z8yqc
pIlMxj10YZA+TYrZ0YvoGS0MkxwBpkHv0KJy9pJ2o83IFkosNRhB6pXr4F/rMiWUYf
QV6xys8Kw9kS0KeflFrKawRteQtYI65hICG/iMEv8bHy6FQqxRZJPHASDExWto/RWh
h5dibe30D8PewZue2P5JqaN5/7Aje3+rFeyEgiSOHyV2qStUjfWGgv9sEMfkucdVD+
xk+j9HdPay9nQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1BD24816A5;
Sun, 1 Feb 2026 10:14:39 -0500 (EST)
Received: from pastel (104-195-243-38.cpe.teksavvy.com [104.195.243.38])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id DE011120AD9;
Sun, 1 Feb 2026 10:14:38 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers
In-Reply-To: <86v7gh4rx3.fsf@HIDDEN>
Message-ID: <jwv4io0h63j.fsf-monnier+emacs@HIDDEN>
References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN>
<jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN>
<jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN>
<86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN>
<861pj568ht.fsf@HIDDEN> <86v7gh4rx3.fsf@HIDDEN>
Date: Sun, 01 Feb 2026 10:14:38 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.137 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80286
Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> > > Btw, we could perhaps detect the situation where condition-wait is
>> > > called when there's only one thread in the list of threads, and signal
>> > > an error in that case, which would prevent the deadlock. But somehow
>> > > my impression was that this is not the solution you are looking for.
>> > Rather than signal an error, it could spawn a thread that
>> > does `accept-process-output`.
>> That'd be very unusual and unexpected, I think.
Timers/filters/sentinels are the closest thing ELisp has to hardware
interrupts. These don't run in any specific thread.
So I disagree with "unusual" and "unexpected".
> Let me turn the table ask: why would the main thread use
> condition-wait to wait for something it itself does?
It doesn't do it itself: the thing it's waiting for will be done by
something else which runs asynchronously (a timer, a process sentinel).
It's just that currently, when that async "signal/interrupt" shows up,
Emacs insists on running the handler in one of the existing threads.
> We have so many other, simpler ways of doing that, and so I wonder why
> should we be bothered by this strange use case?
The concrete use-case where it showed up is
`futur-blocking-wait-to-get-result` (below, excerpted from
a WiP future/promise package).
As you can see, I do have an alternative implementation that uses those
"simpler ways" (called `futur-blocker-wait`), but:
- It's much less simple than the "obvious" alternative of letting the
future/promise call `condition-notify` when it's done.
- It does not wake up right away because we have to add extra waits
where we don't really know what to wait for, so we have to use
a busy-wait loop with an arbitrary timeout.
- It's less efficient because of that busy-wait loop.
So if the timeout in the busy-wait loop is too short, we waste resources
spinning in the loop, and if it's too long, we add extra delays where
Emacs could continue working but sits there waiting for nothing instead.
=== Stefan
(defun futur-blocking-wait-to-get-result (futur)
"Wait for FUTUR to deliver and then return its value.
Ideally, this should never be used, hence the long name to discourage
abuse. Instead, you should use `futur-bind' or `futur-let*' to execute
what you need when FUTUR completes."
;; Waiting for a task to finish has always been a PITA in ELisp,
;; because `sit-for/accept-process-output/sleep-for' have proved brittle
;; with lots of weird corner cases. `futur-blocker-wait' does its best,
;; thanks to years of bug fixing, but it's still messy and brittle.
;; See the VCS history of `url-retrieve-synchronously' for another example.
;; The use of `condition-notify' should side-step this problem, except
;; that bug#80286 means that `condition-wait' can lock up your
;; Emacs session hard.
(if futur--bug80286-is-not-fixed
(futur-blocker-wait futur)
(let* ((mutex (make-mutex "futur-wait"))
(condition (make-condition-variable mutex)))
(with-mutex mutex
(futur--bind futur (lambda (_err _val)
(with-mutex mutex
(condition-notify condition))))
(condition-wait condition))))
(pcase-exhaustive futur
((futur-error err) (futur--resignal err))
((futur-done val) val)))
[...]
(cl-defgeneric futur-blocker-wait (_object)
"Wait for OBJECT to complete.
OBJECT is an object some FUTUR is waiting.
Return non-nil if we successfully waited until the completion of BLOCKER."
nil)
[...]
(cl-defmethod futur-blocker-wait ((futur futur))
(if (not (futur--waiting-p futur))
nil ;; FUTUR already completed.
(let ((i 0))
(while
(pcase futur
((futur-waiting blocker)
(if (futur-blocker-wait blocker)
(setq i 0)
(let ((delay (* 0.01 (expt 1.1 i))))
(if (> delay 1.0)
(sit-for 0) ;; Just redisplay every 1s, just in case.
(setq i (1+ i)))
(accept-process-output nil delay)))
;; Always retry since even if `futur-blocker-wait' succeeded,
;; the futur might not have completed yet (and it may have
;; a new blocker).
t)))
t)))
[...]
(cl-defmethod futur-blocker-wait ((timer (head timer)))
(setq timer (cdr timer))
;; No support for repeated timers (yet?).
(cl-assert (not (timer--repeat-delay timer)))
(if (timer--triggered timer)
nil ;; Already completed.
(while (not (timer--triggered timer))
(let* ((idle (timer--idle-delay timer))
(time (timer--time timer))
(delay (time-to-seconds
(if idle time (time-subtract time (current-time))))))
(accept-process-output nil (min 1.0 (max 0.01 delay)))
(if (> delay 1) (sit-for 0)))) ;; Redisplay every 1s, just in case.
t))
[...]
(cl-defmethod futur-blocker-wait ((proc process))
(if (futur--process-completed-p proc)
nil
(while (and
(not (futur--process-completed-p proc))
(accept-process-output proc 1.0))
(sit-for 0)) ;; Redisplay every 1s, just in case.
t))
[...]
(cl-defmethod futur-blocker-wait ((th thread))
(if (not (thread-live-p th))
nil
(thread-join th)
t))
[...]
(cl-defmethod futur-blocker-wait ((blockers cons))
(let ((waited nil))
(dolist (blocker blockers)
(when (futur-blocker-wait blocker) (setq waited t)))
waited))
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 31 Jan 2026 17:24:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 31 12:24:03 2026 Received: from localhost ([127.0.0.1]:55867 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vmEhW-0007Ad-0j for submit <at> debbugs.gnu.org; Sat, 31 Jan 2026 12:24:02 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58106) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vmEhT-00079k-M9 for 80286 <at> debbugs.gnu.org; Sat, 31 Jan 2026 12:24:00 -0500 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 <eliz@HIDDEN>) id 1vmEhO-0006Y1-8N; Sat, 31 Jan 2026 12:23:54 -0500 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=biw9NZGkdF9HYZJP4zACnmACnSPVQ75qg6aLOqN5pEQ=; b=OdzQAEHbG0xJ SBD2ahLv1mYoh/NEcQvJc4rRMK0NXE6LUAVz9AVwy1rh8YcqgEbZ9L2GjF5OHH1O34QgksA+KUKOG cT7/NOfhI3/IVEg28mKVbBJsYT9JOKmWwBTTcHcGHKxR5Crl9spPYIgBQ/oDgaLBD4LpNbgdNv5ai rturENCL21XjqLj6dMb0VipVrFE2w48I45JfCqP6g3OEcDDkPjS1RMRrcStJnUbp1rq7bQI/p98td tC/nN/EJGB9uZSd/gIrBN4reJEowxBITzdVKbaQLC4FoBqf+8OcNa8ZulGoSD7J3UH+P/lqLVc0BO w2kkD3xhw4L/jPw/GWL27A==; Date: Sat, 31 Jan 2026 19:23:52 +0200 Message-Id: <86v7gh4rx3.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: monnier@HIDDEN In-Reply-To: <861pj568ht.fsf@HIDDEN> (message from Eli Zaretskii on Sat, 31 Jan 2026 18:40:30 +0200) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> <861pj568ht.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN > Date: Sat, 31 Jan 2026 18:40:30 +0200 > From: Eli Zaretskii <eliz@HIDDEN> > > > From: Stefan Monnier <monnier@HIDDEN> > > Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN > > Date: Sat, 31 Jan 2026 11:16:32 -0500 > > > > > Btw, we could perhaps detect the situation where condition-wait is > > > called when there's only one thread in the list of threads, and signal > > > an error in that case, which would prevent the deadlock. But somehow > > > my impression was that this is not the solution you are looking for. > > > > Rather than signal an error, it could spawn a thread that > > does `accept-process-output`. > > That'd be very unusual and unexpected, I think. Let me turn the table ask: why would the main thread use condition-wait to wait for something it itself does? We have so many other, simpler ways of doing that, and so I wonder why should we be bothered by this strange use case?
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.
Received: (at 80286) by debbugs.gnu.org; 31 Jan 2026 17:08:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 31 12:08:51 2026
Received: from localhost ([127.0.0.1]:55666 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vmESp-0005pb-4W
for submit <at> debbugs.gnu.org; Sat, 31 Jan 2026 12:08:51 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:44208)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vmESl-0005oL-Pe
for 80286 <at> debbugs.gnu.org; Sat, 31 Jan 2026 12:08:48 -0500
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 <eliz@HIDDEN>)
id 1vmESg-0004d1-9k; Sat, 31 Jan 2026 12:08:42 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
Date; bh=gW6KWk010CnkYv+hpEMhpjX+qTw3+IQZ6pRirsjsjVc=; b=ASBm4hvw6hW4Tvl0Tk3j
vDmZ4+P3lMj5ccOxwJNs8htIY+9CrudZVXU5W4G3kuoKYsC0HVbnFDIcARoJzyzGs+ZNXvRMu+meH
Div5OY3tR/Qhu2NXFuPVnwhEPz/1j68GbcFjCvjntuxagEMWeHPmvnpME6x0cdfg2E8l48X5rPEQ7
fRMpjf4Ma49W5zM24m3oc6HfDfa0lZB8PVRgQCUSMUrg9lnXHM7jOziyXBVTBQTKjSP9SVKY1O42E
UldAhZgp+mYM940Evdf/XEG4ruRPhCMn/IYehdliwqBRiOF6RUTf5Zb3GC6cUKmCmw96Chp5mer03
dYLIMBr6PPMIZw==;
Date: Sat, 31 Jan 2026 19:08:40 +0200
Message-Id: <86zf5t4smf.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> (message from Stefan
Monnier on Fri, 30 Jan 2026 10:26:39 -0500)
Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers
References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN>
<jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80286
Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: Stefan Monnier <monnier@HIDDEN>
> Cc: 80286 <at> debbugs.gnu.org, John Wiegley <johnw@HIDDEN>
> Date: Fri, 30 Jan 2026 10:26:39 -0500
>
> On a related note, I added the following test to `test/src/thread-tests.el`:
>
> (ert-deftest thread-bug80286-workaround ()
> (let ((my-wait (lambda (delay)
> (let* ((m (make-mutex))
> (c (make-condition-variable m)))
> (with-mutex m
> (run-with-timer delay nil
> (lambda ()
> (with-mutex m (condition-notify c))))
> (condition-wait c)))))
> (idle-loop ;; Idle loop to circumvent the bug.
> (make-thread (lambda () (while t (accept-process-output nil 20.0)))))
> (start-time (float-time)))
> (funcall my-wait 0.01)
> (should (< (- (float-time) start-time) 1))))
>
> and `make test/src/thread-tests` does succeed, bit it takes 20s longer
> than before, so something somewhere is waiting for the dummy
> `accept-process-output` to terminate, which means that my workaround of
> adding a dummy idle threat that loops around `accept-process-output`
> is not harmless 🙁
This is completely unrelated. What waits is one of the following
tests:
(ert-deftest threads-condvar-wait ()
"Test waiting on conditional variable."
(skip-unless (featurep 'threads))
(let ((cv-mutex (make-mutex))
new-thread)
;; We could have spurious threads from the previous tests still
;; running; wait for them to die.
(while (> (length (all-threads)) 1) <<<<<<<<<<<<<<<<
(thread-yield))
Since ERT runs tests in alphabetic order, your added test runs before
threads-condvar-wait, and so threads-condvar-wait waits for the
additional thread to die, which takes 20 sec, as we know from past
discussions of what accept-process-output does in this case.
If you run the code of your test separately, you will see that the
time it takes is slightly longer that the argument to my-wait, which
is expected.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 31 Jan 2026 16:40:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 31 11:40:41 2026 Received: from localhost ([127.0.0.1]:55367 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vmE1Z-0003Jo-Jp for submit <at> debbugs.gnu.org; Sat, 31 Jan 2026 11:40:41 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46248) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vmE1W-0003JV-MF for 80286 <at> debbugs.gnu.org; Sat, 31 Jan 2026 11:40:39 -0500 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 <eliz@HIDDEN>) id 1vmE1R-0006lI-66; Sat, 31 Jan 2026 11:40:33 -0500 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=oeTk94SF/f5AXnFI7o1bwKLXq08eQqjh5DvAzlzivQs=; b=njpZbyfDgdYo y4SMA4HmO3/gUOjuOMC1hoT7z/bNEGQQ1p7JLr1Sg2IJuzL8bl/4EF/mflqDhXkaCbajQg1lmy++r BdfFwTD2X5hZ88CfA5inzFB/2HnFlXZ0Xlc7ftuQBlOR3021jGdOry9oaVZvGcEzcBHuxraiGSdg4 yh7nWnlBKWbCpouONnCvVkbmy3nvMka3bYEmXP5OCt/JX3gzQyLO7pQ+GAT4tG5pi84FnZg4hUsAW qCWdsOj9x2w3nehQ3q+FUdvDBY94fsNZz16LZehBI27ZuJy/v9y9AirL5N4VOI+x0kuskD9Bu8Ifw YyMjmK4tkp9PqUPCpja2kg==; Date: Sat, 31 Jan 2026 18:40:30 +0200 Message-Id: <861pj568ht.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sat, 31 Jan 2026 11:16:32 -0500) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN > Date: Sat, 31 Jan 2026 11:16:32 -0500 > > > Btw, we could perhaps detect the situation where condition-wait is > > called when there's only one thread in the list of threads, and signal > > an error in that case, which would prevent the deadlock. But somehow > > my impression was that this is not the solution you are looking for. > > Rather than signal an error, it could spawn a thread that > does `accept-process-output`. That'd be very unusual and unexpected, I think.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 31 Jan 2026 16:16:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 31 11:16:42 2026 Received: from localhost ([127.0.0.1]:55151 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vmDeL-0000yT-PS for submit <at> debbugs.gnu.org; Sat, 31 Jan 2026 11:16:42 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:44722) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vmDeJ-0000xY-Pn for 80286 <at> debbugs.gnu.org; Sat, 31 Jan 2026 11:16:40 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 64F3B81B12; Sat, 31 Jan 2026 11:16:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1769876193; bh=Xi1/L2e2P2qE03FHsqSoUdIf0XaPMsiLzovYWCs8XEU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Q180VrlRpys3M8zXxXrUNdgxRwAVrnm0Udd9T7E0djkTbqi/b8JNAZ8divSiCZdza u4b3IDerK2oWe9duRqXlh81ZRl/CpeepIa+rmECW42cwOp5krmGny0B5JQvbFX9Y8p rlgQ2H1Hs8/UISf64JDKV4dyBMq/CZcxyWWD72LJDNqNDpWsCegDTo6x7pQyijw02G HzoJuTZemiH4qDLk4BPq7zsGaCwl3fIMTyFo9RvmNC8f/M6+4SBi16K3HwbQ0vua1r YMbWP5TeBMXJr/fjL6mK51rvP6d49k1iQWaom1YznDAI5ivNanSnLxfwPQRyLLX0mE 8L3ogGT7c38eg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7953080883; Sat, 31 Jan 2026 11:16:33 -0500 (EST) Received: from pastel (104-195-243-38.cpe.teksavvy.com [104.195.243.38]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 429CB1208CA; Sat, 31 Jan 2026 11:16:33 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers In-Reply-To: <86tsw26wuy.fsf@HIDDEN> Message-ID: <jwvldhdlpyh.fsf-monnier+emacs@HIDDEN> References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> <86tsw26wuy.fsf@HIDDEN> Date: Sat, 31 Jan 2026 11:16:32 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.139 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Until then, the main loop of the main thread is the only way of > running them, so they are, in fact, tied to the main thread. AFAIK, they can be run by any thread, not just the main thread. >> > More specifically, the author can choose between different harms: either >> > an occasional undesirable delay when exiting, or an undesirable constant >> > spurious activity if the delay is made short enough not to be annoying. >> >> Not if the author writes a Lisp program which doesn't have these bugs. > > Btw, we could perhaps detect the situation where condition-wait is > called when there's only one thread in the list of threads, and signal > an error in that case, which would prevent the deadlock. But somehow > my impression was that this is not the solution you are looking for. Rather than signal an error, it could spawn a thread that does `accept-process-output`. === Stefan
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 31 Jan 2026 07:54:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 31 02:54:23 2026 Received: from localhost ([127.0.0.1]:49460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vm5oE-0001FM-Sx for submit <at> debbugs.gnu.org; Sat, 31 Jan 2026 02:54:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41794) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vm5oC-0001EQ-Oy for 80286 <at> debbugs.gnu.org; Sat, 31 Jan 2026 02:54:21 -0500 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 <eliz@HIDDEN>) id 1vm5o7-0004qV-1e; Sat, 31 Jan 2026 02:54:15 -0500 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=Y4P/PYDWwSxsLJ5cqmd+mCsT5ltSyGMA/HfIXA1RvGw=; b=mP0nTal0Kry1 pIeJMKNF0RaXP5x2ZUVsKDXXGOcsqfaVfG0ARU2R/hmzfP7m448hYQTO7TW62dIRmbUmu2iO3EQ/4 ppGoVNq+XnpJUoh8sIoUqk0rQSQGi0ZTpt21l9hf3lQAjWq3BchYyLSwNm3GCizpTNz5xLwzDukCA kTKaZ1C2h35eV6L7OA+0d6s4RGHJAOeVa0rlRPex47FfxAS6YR87A28Yy8UcgxsN8eGC29ojHVzLu PsGno5I5uUnJ8ce9L/+r5kT343kEkJMt5NstnuboJmvehD4eGhaTEoWpCU0EfSXxRLyf6ss9F6+oJ 6W7SbbB/PLxQpg8l+azSkw==; Date: Sat, 31 Jan 2026 09:54:13 +0200 Message-Id: <86tsw26wuy.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: monnier@HIDDEN In-Reply-To: <865x8i975i.fsf@HIDDEN> (message from Eli Zaretskii on Fri, 30 Jan 2026 22:28:57 +0200) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> <865x8i975i.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN > Date: Fri, 30 Jan 2026 22:28:57 +0200 > From: Eli Zaretskii <eliz@HIDDEN> > > > More specifically, the author can choose between different harms: either > > an occasional undesirable delay when exiting, or an undesirable constant > > spurious activity if the delay is made short enough not to be annoying. > > Not if the author writes a Lisp program which doesn't have these bugs. Btw, we could perhaps detect the situation where condition-wait is called when there's only one thread in the list of threads, and signal an error in that case, which would prevent the deadlock. But somehow my impression was that this is not the solution you are looking for.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 30 Jan 2026 20:29:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 30 15:29:21 2026 Received: from localhost ([127.0.0.1]:44792 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vlv7J-0001WX-1p for submit <at> debbugs.gnu.org; Fri, 30 Jan 2026 15:29:21 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40376) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vlv7D-0001WF-QI for 80286 <at> debbugs.gnu.org; Fri, 30 Jan 2026 15:29:19 -0500 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 <eliz@HIDDEN>) id 1vlv78-0002Cg-7W; Fri, 30 Jan 2026 15:29:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=UAKuRTv0WqEkWKYKNqUm1O22HsqIcderwC5Lu6kH3lU=; b=buozE3qo7kDxGIkpY+Dp qHJaZGAgeLisw+xh5qquUyEH/JMOq1YS4nsOxOqq5coagy4AQm8wnA6a7OoTIQy6WS03qSKpQNoVd rnv5jB82GlSwCrXJETBbzBimNU6s0EaFFrx6VGlRO1Nvtea3LzobOE5Jm+yUSJW89BjAwtVI08K7w YQ8zkznVjtoT7P094gYH1D0Y9oGpo/2NRAQBmyseEPLmh2c25DncoKKdpQg07roZyuJIYHprw4AZ0 9vXFumeO6HDmVdWZPceprNkKiiDhCW6tZokeysOTgd1/KYUp7/O2GmsoQ7+B8Kf4+YIcZB/wFkS3L gzr0TTu5CGIjog==; Date: Fri, 30 Jan 2026 22:28:57 +0200 Message-Id: <865x8i975i.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Fri, 30 Jan 2026 13:59:02 -0500) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN > Date: Fri, 30 Jan 2026 13:59:02 -0500 > > >> AFAIK, timers are not tied to any specific thread, so I don't think it's > >> a "glaring mistake". > > You've caused the main thread, which is the only thread, wait for the > > condvar. Since it's the only thread, which thread did you expect to > > run the timer and signal the condvar? > > > > Timers, as you well know, are run as part of the Emacs's main loop, > > and the main loop is (at least > > by default) run by the main thread. But when the main thread is > > waiting for a condvar, it doesn't get back to the main loop, and thus > > doesn't do what it usually does when it gets there. > > AFAICT you're explaining to me how the code works, but I already > know that. This bug report is about the fact that the resulting > behavior is bad. If you force the only thread in a program to wait on a condvar, you have a bug in your code, and shouldn't expect something to save you from it. > Since timers are not tied to any particular thread, the fact that all > current threads are busy should not be relevant to whether they're run > or not. Patches are welcome to reimplement timers so that they could be run by some other mechanism. Until then, the main loop of the main thread is the only way of running them, so they are, in fact, tied to the main thread. > >> Should I just add a "dummy" > >> > >> (make-thread (lambda () (while t (accept-process-output nil 3600)))) > >> > >> to my package? > > > > That's one way, yes. > > My point is that this is a workaround. If it's needed, than Emacs > should do that "out of the box" without each and every package that > wants to use condition variables notified from > timers/sentinels/... having to do that. You mean, Emacs should start an additional thread when some Lisp defines a condvar and then waits on it? I'm not sure this could be detected reliably, but again, patches are welcome if you know how to do that. Although, to tell the truth, I would find it surprising and unexpected if Emacs would start a thread without me telling it to do so. > >> On a related note, I added the following test to `test/src/thread-tests.el`: > >> > >> (ert-deftest thread-bug80286-workaround () > >> (let ((my-wait (lambda (delay) > >> (let* ((m (make-mutex)) > >> (c (make-condition-variable m))) > >> (with-mutex m > >> (run-with-timer delay nil > >> (lambda () > >> (with-mutex m (condition-notify c)))) > >> (condition-wait c))))) > >> (idle-loop ;; Idle loop to circumvent the bug. > >> (make-thread (lambda () (while t (accept-process-output nil 20.0))))) > >> (start-time (float-time))) > >> (funcall my-wait 0.01) > >> (should (< (- (float-time) start-time) 1)))) > >> > >> and `make test/src/thread-tests` does succeed, bit it takes 20s longer > >> than before, so something somewhere is waiting for the dummy > >> `accept-process-output` to terminate, which means that my workaround of > >> adding a dummy idle threat that loops around `accept-process-output` > >> is not harmless 🙁 > > > > "Not harmless" as in "avoids the deadlock"? > > No: "Not harmless" as in "delays Emacs's exit by 20s". That's because accept-process-output waits for 20 sec with your code. > More specifically, the author can choose between different harms: either > an occasional undesirable delay when exiting, or an undesirable constant > spurious activity if the delay is made short enough not to be annoying. Not if the author writes a Lisp program which doesn't have these bugs.
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 30 Jan 2026 18:59:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 30 13:59:16 2026 Received: from localhost ([127.0.0.1]:44055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vlti7-0003bc-OK for submit <at> debbugs.gnu.org; Fri, 30 Jan 2026 13:59:16 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:33738) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vlti4-0003bM-4W for 80286 <at> debbugs.gnu.org; Fri, 30 Jan 2026 13:59:13 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3174881EA8; Fri, 30 Jan 2026 13:59:06 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1769799545; bh=8sm1sop7R8zq7M8h4ZGpweTpvKSxGqdGzEvPDVEeDEg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=VOpanxsxvJRx8cVXxNG33ZFv9+V4EuusWe5CXgOZgkUlo/GdakTtLiaWpwcjLNjcw rveKIAP199YmskROPEVTml53fhLzxofyOca5Uq+7G23Me7Ftgp3JXDUTWYKrPwyTL9 H1/wyUoDHxteciXK9HoMqScP9ZdrvZ30pesPDjuZXNK0gW+y3h/fj/M6YLTay5JWTZ XrIgr5tHuSQbBMqt3Kozbw7erFbt/iaoKnfqPbiKDJxPmHu01dzIPG51jUB0gzUY+f kPNfGRil44kQXuItYZ/MkOGCcK849my5swFVDbN3Sg3GlEGsLXezMrqQuEgjuQTHNs 6bEbqXhzUaclg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 43332816A5; Fri, 30 Jan 2026 13:59:05 -0500 (EST) Received: from asado (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 273E01201B2; Fri, 30 Jan 2026 13:59:05 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers In-Reply-To: <86a4xv83yp.fsf@HIDDEN> Message-ID: <jwvqzr7c56h.fsf-monnier+emacs@HIDDEN> References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> <86a4xv83yp.fsf@HIDDEN> Date: Fri, 30 Jan 2026 13:59:02 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.157 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) >> AFAIK, timers are not tied to any specific thread, so I don't think it's >> a "glaring mistake". > You've caused the main thread, which is the only thread, wait for the > condvar. Since it's the only thread, which thread did you expect to > run the timer and signal the condvar? > > Timers, as you well know, are run as part of the Emacs's main loop, > and the main loop is (at least > by default) run by the main thread. But when the main thread is > waiting for a condvar, it doesn't get back to the main loop, and thus > doesn't do what it usually does when it gets there. AFAICT you're explaining to me how the code works, but I already know that. This bug report is about the fact that the resulting behavior is bad. Since timers are not tied to any particular thread, the fact that all current threads are busy should not be relevant to whether they're run or not. >> Should I just add a "dummy" >>=20 >> (make-thread (lambda () (while t (accept-process-output nil 3600)))) >>=20 >> to my package? > > That's one way, yes. My point is that this is a workaround. If it's needed, than Emacs should do that "out of the box" without each and every package that wants to use condition variables notified from timers/sentinels/... having to do that. >> On a related note, I added the following test to `test/src/thread-tests.= el`: >>=20 >> (ert-deftest thread-bug80286-workaround () >> (let ((my-wait (lambda (delay) >> (let* ((m (make-mutex)) >> (c (make-condition-variable m))) >> (with-mutex m >> (run-with-timer delay nil >> (lambda () >> (with-mutex m (condition-no= tify c)))) >> (condition-wait c))))) >> (idle-loop ;; Idle loop to circumvent the bug. >> (make-thread (lambda () (while t (accept-process-output nil= 20.0))))) >> (start-time (float-time))) >> (funcall my-wait 0.01) >> (should (< (- (float-time) start-time) 1)))) >>=20 >> and `make test/src/thread-tests` does succeed, bit it takes 20s longer >> than before, so something somewhere is waiting for the dummy >> `accept-process-output` to terminate, which means that my workaround of >> adding a dummy idle threat that loops around `accept-process-output` >> is not harmless =F0=9F=99=81 > > "Not harmless" as in "avoids the deadlock"? No: "Not harmless" as in "delays Emacs's exit by 20s". More specifically, the author can choose between different harms: either an occasional undesirable delay when exiting, or an undesirable constant spurious activity if the delay is made short enough not to be annoying. =3D=3D=3D Stefan
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 30 Jan 2026 16:23:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 30 11:23:40 2026 Received: from localhost ([127.0.0.1]:42908 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vlrHX-0004MI-VX for submit <at> debbugs.gnu.org; Fri, 30 Jan 2026 11:23:40 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45460) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vlrHV-0004M1-57 for 80286 <at> debbugs.gnu.org; Fri, 30 Jan 2026 11:23:38 -0500 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 <eliz@HIDDEN>) id 1vlrHP-0000rR-Cr; Fri, 30 Jan 2026 11:23:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=25TLMzRsj9IPvDWblx0nWnCZKAWX9764qVIXpPS5ck0=; b=Zfuk4wbNdOsYHbGqoQyc lvf879iDu/XkSYKhm1i96Qo68a75VEkblvb2nFT8R28mBhr5B4bQiGwaIvA7JQtd06EbpZZ186R6o 8muNhuJ1ev/QgXRIYxhDAOCyVy82rB2CWaxAmXuZD5q+Zz2iOPRwWiatWlzwqZ2/jffTmK/izpFPn hMcgqn9TUYdnbF8TlXyL/JcCm351LV+42a6GumnswEdv4eqQ6Af6b88UlWPLWcuS7A/+CxkK6iHo5 6FRuvywy2TEn/EsitTjqZ8tRV+x3CaV3qUcU8ORMnKw4OAy52QHHn0gimAUjt3PcxoB90kUCyQ/Iy FQhdP4HP4kyt1A==; Date: Fri, 30 Jan 2026 18:23:10 +0200 Message-Id: <86a4xv83yp.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Fri, 30 Jan 2026 10:26:39 -0500) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN> <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, johnw@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: 80286 <at> debbugs.gnu.org, John Wiegley <johnw@HIDDEN> > Date: Fri, 30 Jan 2026 10:26:39 -0500 > > >> (defun my-wait (delay) > >> (let* ((m (make-mutex)) > >> (c (make-condition-variable m))) > >> (with-mutex m > >> (run-with-timer delay nil > >> (lambda () > >> (with-mutex m (condition-notify c)))) > >> (condition-wait c)))) > [...] > > condition-wait makes the calling thread stuck waiting for the condvar > > to become signaled. If there's no other thread running which is > > programmed (or could be made) to signal the condvar, the lone thread > > that's waiting for the condvar will wait forever. (Isn't this what > > happens in any program whose sole thread waits for a condvar?) What > > can we do if the programmer makes such a glaring mistake? > > AFAIK, timers are not tied to any specific thread, so I don't think it's > a "glaring mistake". You've caused the main thread, which is the only thread, wait for the condvar. Since it's the only thread, which thread did you expect to run the timer and signal the condvar? Timers, as you well know, are run as part of the Emacs's main loop, and the main loop is (at least by default) run by the main thread. But when the main thread is waiting for a condvar, it doesn't get back to the main loop, and thus doesn't do what it usually does when it gets there. > Worse, as a programmer, I'm not sure how to avoid making such a > "mistake". Have at least one more thread, that's how. > Should I just add a "dummy" > > (make-thread (lambda () (while t (accept-process-output nil 3600)))) > > to my package? That's one way, yes. > On a related note, I added the following test to `test/src/thread-tests.el`: > > (ert-deftest thread-bug80286-workaround () > (let ((my-wait (lambda (delay) > (let* ((m (make-mutex)) > (c (make-condition-variable m))) > (with-mutex m > (run-with-timer delay nil > (lambda () > (with-mutex m (condition-notify c)))) > (condition-wait c))))) > (idle-loop ;; Idle loop to circumvent the bug. > (make-thread (lambda () (while t (accept-process-output nil 20.0))))) > (start-time (float-time))) > (funcall my-wait 0.01) > (should (< (- (float-time) start-time) 1)))) > > and `make test/src/thread-tests` does succeed, bit it takes 20s longer > than before, so something somewhere is waiting for the dummy > `accept-process-output` to terminate, which means that my workaround of > adding a dummy idle threat that loops around `accept-process-output` > is not harmless 🙁 "Not harmless" as in "avoids the deadlock"?
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.
Received: (at 80286) by debbugs.gnu.org; 30 Jan 2026 15:26:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 30 10:26:51 2026
Received: from localhost ([127.0.0.1]:41990 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vlqOY-0007tE-KX
for submit <at> debbugs.gnu.org; Fri, 30 Jan 2026 10:26:51 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:40053)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vlqOW-0007sv-9x
for 80286 <at> debbugs.gnu.org; Fri, 30 Jan 2026 10:26:48 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BD2F744142C;
Fri, 30 Jan 2026 10:26:41 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1769786800;
bh=8stF2nR+nGqiip/7vU7yxM7PF8zQ3xFyu/Dffw20Lgc=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=eDsHjbgRh35aqEMHbWL02kWSmWZb238y0Q3FSxwqPnyg+0zKT3b6DzE5DD5WCWMdf
fuxhdUUt2ZW2lQ06/+aKJBplo53A/QafcuIxLa2srNLpR0Su/TqsKMKnH3wp7jbV4v
zcy1Tvfgllev+stbQbpzjYHvOkEEp10B6beTthYQP+hBIy/zk5d1j7q84IG5AR7iMj
ry4Ltoq7eWEZnA1XAPzskASrNxiuMcK9ikzHYxQPpdKj+C4Zda+sDbqxzF+b4OzSHG
cKc64CinTX+iCb1rMadPyiL1RMbQazwzUkPqRO7Bzzf6dRMuaHxuw+ms/xZi2/yYmR
QCiNv70QfHm3A==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 78DFA440388;
Fri, 30 Jan 2026 10:26:40 -0500 (EST)
Received: from pastel (104-195-243-38.cpe.teksavvy.com [104.195.243.38])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 479A21201D2;
Fri, 30 Jan 2026 10:26:40 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers
In-Reply-To: <86cy2ra6sr.fsf@HIDDEN>
Message-ID: <jwvfr7nm8sa.fsf-monnier+emacs@HIDDEN>
References: <jwvjyx03xtf.fsf-monnier+@gnu.org> <86cy2ra6sr.fsf@HIDDEN>
Date: Fri, 30 Jan 2026 10:26:39 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.226 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80286
Cc: 80286 <at> debbugs.gnu.org, John Wiegley <johnw@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> (defun my-wait (delay)
>> (let* ((m (make-mutex))
>> (c (make-condition-variable m)))
>> (with-mutex m
>> (run-with-timer delay nil
>> (lambda ()
>> (with-mutex m (condition-notify c))))
>> (condition-wait c))))
[...]
> condition-wait makes the calling thread stuck waiting for the condvar
> to become signaled. If there's no other thread running which is
> programmed (or could be made) to signal the condvar, the lone thread
> that's waiting for the condvar will wait forever. (Isn't this what
> happens in any program whose sole thread waits for a condvar?) What
> can we do if the programmer makes such a glaring mistake?
AFAIK, timers are not tied to any specific thread, so I don't think it's
a "glaring mistake". Worse, as a programmer, I'm not sure how to avoid
making such a "mistake". Should I just add a "dummy"
(make-thread (lambda () (while t (accept-process-output nil 3600))))
to my package?
> Add some special handling for C-g (perhaps after C-g is pressed
> several times) if we detect such a situation?
The fact that `C-g` can't get me out of the hang is annoying, but I'm
more interested in avoiding the hang in the first place.
On a related note, I added the following test to `test/src/thread-tests.el`:
(ert-deftest thread-bug80286-workaround ()
(let ((my-wait (lambda (delay)
(let* ((m (make-mutex))
(c (make-condition-variable m)))
(with-mutex m
(run-with-timer delay nil
(lambda ()
(with-mutex m (condition-notif=
y c))))
(condition-wait c)))))
(idle-loop ;; Idle loop to circumvent the bug.
(make-thread (lambda () (while t (accept-process-output nil 20=
.0)))))
(start-time (float-time)))
(funcall my-wait 0.01)
(should (< (- (float-time) start-time) 1))))
and `make test/src/thread-tests` does succeed, bit it takes 20s longer
than before, so something somewhere is waiting for the dummy
`accept-process-output` to terminate, which means that my workaround of
adding a dummy idle threat that loops around `accept-process-output`
is not harmless =F0=9F=99=81
=3D=3D=3D Stefan
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.Received: (at 80286) by debbugs.gnu.org; 30 Jan 2026 07:39:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 30 02:39:14 2026 Received: from localhost ([127.0.0.1]:36277 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vlj61-0006TN-Uj for submit <at> debbugs.gnu.org; Fri, 30 Jan 2026 02:39:14 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48324) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vlj5z-0006T1-Mm for 80286 <at> debbugs.gnu.org; Fri, 30 Jan 2026 02:39:12 -0500 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 <eliz@HIDDEN>) id 1vlj5u-0003Ea-0A; Fri, 30 Jan 2026 02:39:06 -0500 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=3LwvWNKhcGXyrekiNqSHggrTSXYRj8gBtYo9mLPJa0Y=; b=mpuDeHjGhif9 KPG4rvWg90hZNDMKoNypvkO2htGzmipH5lQqP7mwZWAE42QequSn7j+Hjq3TbgV1ppXcQ8REWSAno GXqa6Y0nlM0ROXCBdUohoIL0EsEjWcQIJTr/Qx8KtMgSTkTxmUXri+CsB2pSGQEfda7qmkBcKjq0N lvLMwpRp+SQzJwBJv/C76c6iP4pP/P3xmn0XcefKC4rgvd+Xhw2qLUyJiId+UmYB5luiJk+3ev+NX IDdw4ODl2XuOTdE9VHUubMpgikWGsK56hn2Rigo/sDVk9ICGE9Kd2d4/n0oT1B6H8r9qlw7nO9Yrw 2jXXUL84wNzVWLreHZZBGw==; Date: Fri, 30 Jan 2026 09:39:00 +0200 Message-Id: <86cy2ra6sr.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvjyx03xtf.fsf-monnier+@gnu.org> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#80286: 31.0.50; `condition-wait` blocking timers References: <jwvjyx03xtf.fsf-monnier+@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80286 Cc: 80286 <at> debbugs.gnu.org, John Wiegley <johnw@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: monnier@HIDDEN > Date: Thu, 29 Jan 2026 16:48:02 -0500 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > If you define: > > (defun my-wait (delay) > (let* ((m (make-mutex)) > (c (make-condition-variable m))) > (with-mutex m > (run-with-timer delay nil > (lambda () > (with-mutex m (condition-notify c)))) > (condition-wait c)))) > > and then try > > M-: (make-thread (lambda () (my-wait 1) (message "hello"))) RET > > you'll indeed see a "hello" message after 1s. Good! > But if you try > > M-: (progn (my-wait 1) (message "hello")) RET > > then your Emacs session will be frozen. > > You avoid that nasty situation if you happen to have another thread > around that might run the timers. E.g. if you first do > > M-: (setq myt (make-thread (lambda () (while t (accept-process-output nil 1.0))))) > > and then do > > M-: (progn (my-wait 1) (message "hello")) RET > > I think we should somehow make sure `condition-wait` never locks up the > session like that. Presumably the same applies to `mutex-lock`, tho > I haven't checked. condition-wait makes the calling thread stuck waiting for the condvar to become signaled. If there's no other thread running which is programmed (or could be made) to signal the condvar, the lone thread that's waiting for the condvar will wait forever. (Isn't this what happens in any program whose sole thread waits for a condvar?) What can we do if the programmer makes such a glaring mistake? Add some special handling for C-g (perhaps after C-g is pressed several times) if we detect such a situation? John Wiegley suggested several months ago to add an optional timeout argument for condition-wait, see https://lists.gnu.org/archive/html/emacs-devel/2025-07/msg00116.html I had some minor comments to the patch, here: https://lists.gnu.org/archive/html/emacs-devel/2025-07/msg00127.html but then we dropped the ball on this. How about respinning and installing something like that?
bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 29 Jan 2026 21:48:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 29 16:48:17 2026
Received: from localhost ([127.0.0.1]:60788 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vlZs8-0005uI-JJ
for submit <at> debbugs.gnu.org; Thu, 29 Jan 2026 16:48:16 -0500
Received: from lists.gnu.org ([2001:470:142::17]:38098)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vlZs6-0005u5-5i
for submit <at> debbugs.gnu.org; Thu, 29 Jan 2026 16:48:14 -0500
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 <monnier@HIDDEN>)
id 1vlZrz-0007JG-2J
for bug-gnu-emacs@HIDDEN; Thu, 29 Jan 2026 16:48:07 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <monnier@HIDDEN>)
id 1vlZrx-0003HL-NJ
for bug-gnu-emacs@HIDDEN; Thu, 29 Jan 2026 16:48:06 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9F02D441C33;
Thu, 29 Jan 2026 16:48:03 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1769723282;
bh=Jti+GdjRlFfl1AkrEe3LUE8q78Ntx5LbvfI/OjuelL4=;
h=From:To:Subject:Date:From;
b=Nyg+fnXUu2k9QRShpWy0pmMOc/8Gl5RoOx+TtDR2H+nZ+tkbfSDllVP8CZ6hETXLN
SrAubUuAtI79mHKGyNOCra98S1Kf54b6e/sth2zUVfNlx3tC1pCA4GIXL1VYHcLn4U
sYMvw34jG5W0tYQoVatUms7BGhYhArpS5jfsMRDcJGA3to2ksjnJZlsdIwBbeHxzji
Fop0MwhMaGcnErCHbpxKFG9BvaQEVxbLeAGD4OMSnA40upXnpHMSvmEVb6NO+4Lg5S
XlBBJuz/pfdNOa3AITpzrKJ8sfdONCLvb0ew/dExltYptoHBQ7IYNKyBAX+p4wJxm1
ywtDdZlnppr2Q==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 899AF441C2E;
Thu, 29 Jan 2026 16:48:02 -0500 (EST)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 71FB01200C7;
Thu, 29 Jan 2026 16:48:02 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 31.0.50; `condition-wait` blocking timers
Message-ID: <jwvjyx03xtf.fsf-monnier+@gnu.org>
X-Debbugs-Cc: monnier@HIDDEN
Date: Thu, 29 Jan 2026 16:48:02 -0500
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.252 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
Received-SPF: pass client-ip=132.204.25.50;
envelope-from=monnier@HIDDEN; helo=mailscanner.iro.umontreal.ca
X-Spam_score_int: -42
X-Spam_score: -4.3
X-Spam_bar: ----
X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3,
RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Package: Emacs
Version: 31.0.50
If you define:
(defun my-wait (delay)
(let* ((m (make-mutex))
(c (make-condition-variable m)))
(with-mutex m
(run-with-timer delay nil
(lambda ()
(with-mutex m (condition-notify c))))
(condition-wait c))))
and then try
M-: (make-thread (lambda () (my-wait 1) (message "hello"))) RET
you'll indeed see a "hello" message after 1s. Good!
But if you try
M-: (progn (my-wait 1) (message "hello")) RET
then your Emacs session will be frozen.
You avoid that nasty situation if you happen to have another thread
around that might run the timers. E.g. if you first do
M-: (setq myt (make-thread (lambda () (while t (accept-process-output nil 1.0)))))
and then do
M-: (progn (my-wait 1) (message "hello")) RET
I think we should somehow make sure `condition-wait` never locks up the
session like that. Presumably the same applies to `mutex-lock`, tho
I haven't checked.
=== Stefan
Stefan Monnier <monnier@HIDDEN>:monnier@HIDDEN, bug-gnu-emacs@HIDDEN.
Full text available.monnier@HIDDEN, bug-gnu-emacs@HIDDEN:bug#80286; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.