From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 11 21:16:25 2025 Received: (at submit) by debbugs.gnu.org; 12 Mar 2025 01:16:26 +0000 Received: from localhost ([127.0.0.1]:46450 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tsAht-0005oc-IH for submit@debbugs.gnu.org; Tue, 11 Mar 2025 21:16:25 -0400 Received: from lists.gnu.org ([2001:470:142::17]:50442) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tsAhr-0005oK-IV for submit@debbugs.gnu.org; Tue, 11 Mar 2025 21:16:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tsAhk-0002oP-Ah for bug-gnu-emacs@gnu.org; Tue, 11 Mar 2025 21:16:16 -0400 Received: from fout-b4-smtp.messagingengine.com ([202.12.124.147]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tsAhi-0004DC-45 for bug-gnu-emacs@gnu.org; Tue, 11 Mar 2025 21:16:15 -0400 Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfout.stl.internal (Postfix) with ESMTP id AD35B1140257 for ; Tue, 11 Mar 2025 21:16:12 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-07.internal (MEProxy); Tue, 11 Mar 2025 21:16:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:message-id:mime-version:reply-to:subject :subject:to:to; s=fm3; t=1741742172; x=1741828572; bh=sPviu68FzC KeppYYK/XZwuN5vlAmtuVzLe+n2JIYM0c=; b=Iu37saXsBH76qoa7nbXTctnzSw vwiUqZ4c5+r4PoUPfvba74Pzd8js6o+WTLtSrSo2vSy6ZdCLVGCVJZ0HGiwQ74ba 7ZzQOoM+lupxPLsSnsZHeuJbGc/JtyWd3A2Oo6mHIq5LeP1/DEy/BAscpVQcB4cV oYExS5UCvVtl001ub5gPykdu+aIqQ5VKeFA85LDAIfi5iyqogXbgy2gE49WvU3qA R2X+wV2jun1e1UDcMakAnOrSS1gk3sXockn4GWSbnLhtyA2p3GebIJC9gntCti2g PzWy5fpOjrkkrqFB0NunHLBxZp6VJWEwfFr+XqtdvqoUCb7FSiyA2i4mKuEQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1741742172; x=1741828572; bh=sPviu68FzCKeppYYK/XZwuN5vlAmtuVzLe+ n2JIYM0c=; b=D5Z7jUqSzbHWBxdNbFFPHqKe+RHze1mnsWBGgPecIkINL0IKPi5 zEh2TYwjumXDtMrdYwW/jix2J8hQ4TMVd49VjS4+UIhi1FYx1aw2BdVfsLGs+q5o 6BZnYbWD/weYWyZAKRcSg/hM4gMjiew0l5Vs0Jcsjc8IKYT/UCByQJdQkrVlTK8u aXkNIBtPvZsbrH8guc5DBZlGaZ/DFk3wwT3LlXGjnzgaCdYfQN6qu0Uoltr8mRdR nky/BGeJWZmc6bKabVe8HWhY35gBn/UHna51jbPEEyP6J0ZPS5cHItVGEN3dLPf6 zTvURxd+ecwd7N+1+7ewgG9WUASsAqpRdhA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduvdefjedvucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefkff ggfgfvhffutgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcu oegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvghrnhepfeekfeeghf ejveehkedtgefhffejgefgudetgfeguefhteekudeivefghfekgfevnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtoh hvrdguvghvpdhnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhuthdprhgtphht thhopegsuhhgqdhgnhhuqdgvmhgrtghssehgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 11 Mar 2025 21:16:11 -0400 (EDT) Message-ID: Date: Wed, 12 Mar 2025 03:16:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: bug-gnu-emacs@gnu.org From: Dmitry Gutov Subject: kill-buffer fails silently when a thread exists where it's current Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=202.12.124.147; envelope-from=dmitry@gutov.dev; helo=fout-b4-smtp.messagingengine.com X-Spam_score_int: -26 X-Spam_score: -2.7 X-Spam_bar: -- X-Spam_report: (-2.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_SBL_A=0.1 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.4 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: This stems from a private bug report about diff-hl when it uses a thread to update the fringe highlights. To reproduce: 1. Install, enable diff-hl-mode. 2. (setq diff-hl-update-async t) 3. Visit a code buffer in a (e.g.) Git repo, save it. 4. Make an edit, don't save. 5. Evaluate this: Content analysis details: (1.4 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.1 URIBL_SBL_A Contains URL's A record listed in the Spamhaus SBL blocklist [URIs: gutov.dev] 0.6 URIBL_SBL Contains an URL's NS IP listed in the Spamhaus SBL blocklist [URIs: gutov.dev] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.7 SPF_NEUTRAL SPF: sender does not match SPF record (neutral) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2001:470:142:0:0:0:0:17 listed in] [list.dnswl.org] X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.4 (/) This stems from a private bug report about diff-hl when it uses a thread to update the fringe highlights. To reproduce: 1. Install, enable diff-hl-mode. 2. (setq diff-hl-update-async t) 3. Visit a code buffer in a (e.g.) Git repo, save it. 4. Make an edit, don't save. 5. Evaluate this: (progn (save-buffer) (kill-buffer)) Current: The result is that the buffer is not killed. And that happens silently, no errors or anything. Only further examination and reading the sources led to understanding the reason. Expected: It probably should be killed. After the thread is signaled some error (perhaps) and is aborted. And if the buffer can't be killed, 'kill-buffer' itself should exit with an error. As I understand the behavior is old (2013) and comes from the 'thread_check_current_buffer' call in Fkill_buffer. But it's not mentioned in kill-buffer's docstring or the manual. Alternative repro: If you don't have diff-hl installed, you could replace 1 and 2 with: (defun foo () (make-thread (lambda () (sleep-for 0.1)))) (add-hook 'after-save-hook #'foo) From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 13 05:47:55 2025 Received: (at 76969) by debbugs.gnu.org; 13 Mar 2025 09:47:55 +0000 Received: from localhost ([127.0.0.1]:53777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tsfAQ-0008RY-VL for submit@debbugs.gnu.org; Thu, 13 Mar 2025 05:47:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49740) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tsfAO-0008RK-0W for 76969@debbugs.gnu.org; Thu, 13 Mar 2025 05:47:53 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tsfAI-0006MI-CR; Thu, 13 Mar 2025 05:47:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=eW4SOaQm+nhd+0aqQbhzcHy0xVxYoacpX/yIiXIvVHk=; b=YJNLsNJbgstK pKqti/fzOUSVdwXyggFVxCW/7KosYFIMxWryC22GPsp2Hf5WrCydc2PFLXpSAzCe3hU8JQeELc6g9 BxTYhU+onYv9eMWJDnXUDZQLniI7gJ0lAhzl2t6Db/rkNU5AGN+aVGSCWgFSM1rkA9M+nH+GgWhhv UeXPNE7pZIxnYeN0w9wJguSfBBdVdxK062BbDPuTf/ITDebLo/q/9Zhr6Grq6C9OdktLnhDOpaPsm imHXC+Y6/XkkzvXXhZSQFx2dqc5CKeKdT0utuF4bbZt9Ra20MhgOTz7zLuyvFA8wMW9+sVI89rLIN XGyxwDsjSFRRRqAQPLQnvQ==; Date: Thu, 13 Mar 2025 11:47:44 +0200 Message-Id: <86senh2ren.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Wed, 12 Mar 2025 03:16:08 +0200) Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current References: X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 76969 Cc: 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > Date: Wed, 12 Mar 2025 03:16:08 +0200 > From: Dmitry Gutov > > This stems from a private bug report about diff-hl when it uses a thread > to update the fringe highlights. > > To reproduce: > > 1. Install, enable diff-hl-mode. > 2. (setq diff-hl-update-async t) > 3. Visit a code buffer in a (e.g.) Git repo, save it. > 4. Make an edit, don't save. > 5. Evaluate this: > > (progn > (save-buffer) > (kill-buffer)) > > Current: > > The result is that the buffer is not killed. And that happens silently, > no errors or anything. Only further examination and reading the sources > led to understanding the reason. > > Expected: > > It probably should be killed. After the thread is signaled some error > (perhaps) and is aborted. And if the buffer can't be killed, > 'kill-buffer' itself should exit with an error. > > As I understand the behavior is old (2013) and comes from the > 'thread_check_current_buffer' call in Fkill_buffer. But it's not > mentioned in kill-buffer's docstring or the manual. There are other reasons which preclude killing a buffer that aren't mentioned in the doc string. For example, this: /* Don't kill the minibuffer now current. */ if (BASE_EQ (buffer, XWINDOW (minibuf_window)->contents)) return Qnil; or this: /* Make this buffer not be current. Exit if it is the sole visible buffer. */ if (b == current_buffer) { tem = Fother_buffer (buffer, Qnil, Qnil); Fset_buffer (tem); if (b == current_buffer) return Qnil; or this: /* If the buffer now current is shown in the minibuffer and our buffer is the sole other buffer give up. */ XSETBUFFER (tem, current_buffer); if (EQ (tem, XWINDOW (minibuf_window)->contents) && BASE_EQ (buffer, Fother_buffer (buffer, Qnil, Qnil))) return Qnil; So if this is a request to spell out these conditions in the documentation, I'm okay with doing so. But is this the only request here? If not, please elaborate. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 13 08:10:49 2025 Received: (at 76969) by debbugs.gnu.org; 13 Mar 2025 12:10:49 +0000 Received: from localhost ([127.0.0.1]:54042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tshOi-0004NZ-QM for submit@debbugs.gnu.org; Thu, 13 Mar 2025 08:10:49 -0400 Received: from fout-a7-smtp.messagingengine.com ([103.168.172.150]:56743) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tshOf-0004NG-7k for 76969@debbugs.gnu.org; Thu, 13 Mar 2025 08:10:45 -0400 Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfout.phl.internal (Postfix) with ESMTP id E578F1383167; Thu, 13 Mar 2025 08:10:39 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-10.internal (MEProxy); Thu, 13 Mar 2025 08:10:39 -0400 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=fm3; t=1741867839; x=1741954239; bh=KiKu0DHMeemuQ+RQ8gkUeQmiScl4PfeGNHeksJn+uhc=; b= WRvQ1Jo05RtckjzEX2mpAjax6wfOnYRevk1BMB5bkVSjFS4pc4FcaJL236Vckg6C zfiR38grF/wzfR5qtySSYoD8xLi4ObQU+zDT+ntjhUxbdOG6bYGTB2VcdPhQOqkN sheOi/7A/w5OTGAFzph6vZEqmD4WA1AeBaMNQ+sHVU4Kipl3d6TNB2u/FoneJGlU Lyd+ejdKWX8rL8mizRjW8E344PZEGEbJ06kHZMBc/AoVws1Z0AyykEFIIgX3BpnB hFM3pcomzJ+OHGrbSNBxMnT8iRyjFnbyO6fJCMgdnKYETV+Uxvl+6A+sK39qVii9 lCts5XCgTxouUA5Zhi9ezQ== 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=fm1; t=1741867839; x= 1741954239; bh=KiKu0DHMeemuQ+RQ8gkUeQmiScl4PfeGNHeksJn+uhc=; b=6 XDpsJEtkaz0Vfn5E5oDGc3WwgHkX2fTiQIYeUHzRjsF+Hmof9nK09JalXnPCVz7T eCI+h/i1C2Qcwd5TQsoGoL6JD1LFpb66Es9u4LZrMYHfbKmCJKjmhqVRNLfeWYUD /3ub85W8Yt0PG3eZsy0pKVOSnSY5ed9VPJmTYzBCQ3ut0yPfYd8wuq8+tM2gbxl0 hOaiI7HaQOqveq/ljp+FufY5nDW6lafW0T2xRWiXARtpLuw5wECA+Vkj29QsoiUi qy1Co6+86COA+ckZUtCvjqz2rC0sngnDYFUHI8AgiZirSP93Yfga23pcJc8RMpSb yiLiDuf47KJGPzB0IW5DA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduvdejleduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddt vdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovh druggvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieek ueeftddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphht thhopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdroh hrghdprhgtphhtthhopeejieelieelseguvggssghughhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 13 Mar 2025 08:10:38 -0400 (EDT) Message-ID: <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> Date: Thu, 13 Mar 2025 14:10:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current To: Eli Zaretskii References: <86senh2ren.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86senh2ren.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76969 Cc: 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 13/03/2025 11:47, Eli Zaretskii wrote: >> Expected: >> >> It probably should be killed. After the thread is signaled some error >> (perhaps) and is aborted. And if the buffer can't be killed, >> 'kill-buffer' itself should exit with an error. >> >> As I understand the behavior is old (2013) and comes from the >> 'thread_check_current_buffer' call in Fkill_buffer. But it's not >> mentioned in kill-buffer's docstring or the manual. > > There are other reasons which preclude killing a buffer that aren't > mentioned in the doc string. For example, this: That's a good point. > /* Don't kill the minibuffer now current. */ > if (BASE_EQ (buffer, XWINDOW (minibuf_window)->contents)) > return Qnil; > > or this: > > /* Make this buffer not be current. Exit if it is the sole visible > buffer. */ > if (b == current_buffer) > { > tem = Fother_buffer (buffer, Qnil, Qnil); > Fset_buffer (tem); > if (b == current_buffer) > return Qnil; > > or this: > > /* If the buffer now current is shown in the minibuffer and our buffer > is the sole other buffer give up. */ > XSETBUFFER (tem, current_buffer); > if (EQ (tem, XWINDOW (minibuf_window)->contents) > && BASE_EQ (buffer, Fother_buffer (buffer, Qnil, Qnil))) > return Qnil; > > So if this is a request to spell out these conditions in the > documentation, I'm okay with doing so. Yes, I think it will be good to note that there are certain rare exceptions (when the buffer is the minibuffer or the sole other buffer), and that kill-buffer will skip killing them and simply return nil without complaint. > But is this the only request > here? If not, please elaborate. The situation with threads seems different because it can affect, potentially, (almost) any Lisp code and almost any buffer that a Lisp program expects to kill. The more often threads are used, the higher the odds will be. And the consequences seem less severe, conceptually, than killing one of the exceptions mentioned above. The exception for threads seems to have been made as a matter of implementation convenience, so it's worth revisiting. To reiterate, having the buffer killed (and the associated thread with it) seems preferable - perhaps after allowing the thread to handle the attempt. And/or if the killing does not happen, showing a warning or an error would be an improvement. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 13 10:59:09 2025 Received: (at 76969) by debbugs.gnu.org; 13 Mar 2025 14:59:09 +0000 Received: from localhost ([127.0.0.1]:57650 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tsk1d-0004g3-Bt for submit@debbugs.gnu.org; Thu, 13 Mar 2025 10:59:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53324) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tsk1b-0004fk-7B for 76969@debbugs.gnu.org; Thu, 13 Mar 2025 10:59:07 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tsk1V-0005rP-Ig; Thu, 13 Mar 2025 10:59:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Ma3z8XU/3TM3Doke/Qj4k/6wSat+w3PTQot920QFyH4=; b=DR+U4nPgXmSH lx8ad3GoGmSWJLvXjAqrYjaegHzgG1enKyqRisEBvPT/godPlY/4+P4I/Mow+PjZBg52Wd+6Xbald xw5YlbxN78X+VYaxQyqyx1T875KhTByo53QtXqOMIf3+KTUiWxpAkwCZ5x59tr9X7D71BoKvzznXF 1zgTy9vNvgdZuqQrTDmhZ44854c24MP6SECx9TOHrHa1r/AdJd6xYIPntM/bCQMPye+XXKCFZsVxH b1zw9zgeWsdIULCFbNnb0qzIckrqDMNknA9yNtsDRDFo1sZ9YppgbOlcv+xBi8nAuxkXyDwxIezwq evrHbyX/sZ2vFvmzu7yq5Q==; Date: Thu, 13 Mar 2025 16:58:56 +0200 Message-Id: <86wmct0yfj.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> (message from Dmitry Gutov on Thu, 13 Mar 2025 14:10:36 +0200) Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 76969 Cc: 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > Date: Thu, 13 Mar 2025 14:10:36 +0200 > Cc: 76969@debbugs.gnu.org > From: Dmitry Gutov > > On 13/03/2025 11:47, Eli Zaretskii wrote: > > > There are other reasons which preclude killing a buffer that aren't > > mentioned in the doc string. For example, this: > > That's a good point. > > > /* Don't kill the minibuffer now current. */ > > if (BASE_EQ (buffer, XWINDOW (minibuf_window)->contents)) > > return Qnil; > > > > or this: > > > > /* Make this buffer not be current. Exit if it is the sole visible > > buffer. */ > > if (b == current_buffer) > > { > > tem = Fother_buffer (buffer, Qnil, Qnil); > > Fset_buffer (tem); > > if (b == current_buffer) > > return Qnil; > > > > or this: > > > > /* If the buffer now current is shown in the minibuffer and our buffer > > is the sole other buffer give up. */ > > XSETBUFFER (tem, current_buffer); > > if (EQ (tem, XWINDOW (minibuf_window)->contents) > > && BASE_EQ (buffer, Fother_buffer (buffer, Qnil, Qnil))) > > return Qnil; > > > > So if this is a request to spell out these conditions in the > > documentation, I'm okay with doing so. > > Yes, I think it will be good to note that there are certain rare > exceptions (when the buffer is the minibuffer or the sole other buffer), > and that kill-buffer will skip killing them and simply return nil > without complaint. OK, we can extend the doc string with these caveats. > > But is this the only request > > here? If not, please elaborate. > > The situation with threads seems different because it can affect, > potentially, (almost) any Lisp code and almost any buffer that a Lisp > program expects to kill. The more often threads are used, the higher the > odds will be. > > And the consequences seem less severe, conceptually, than killing one of > the exceptions mentioned above. The exception for threads seems to have > been made as a matter of implementation convenience, so it's worth > revisiting. If we want to kill a buffer that is the current buffer of some thread, we must do the same thing we do when killing the buffer that is current in the thread which calls kill-buffer: replace it with some other buffer, if possible: /* Make this buffer not be current. Exit if it is the sole visible buffer. */ if (b == current_buffer) { tem = Fother_buffer (buffer, Qnil, Qnil); Fset_buffer (tem); if (b == current_buffer) return Qnil; } > To reiterate, having the buffer killed (and the associated thread with > it) seems preferable - perhaps after allowing the thread to handle the > attempt. You forget that the other thread (the one which uses the buffer as the current) cannot do anything because it is blocked trying to take the global lock, while this thread, the one which called kill-buffer, runs. The only way to allow that thread to do anything would be to defer to that thread to do the killing, and yield the global lock to it so it could actually do that. But this requires infrastructure we don't have, because we cannot currently yield to a specific thread. > And/or if the killing does not happen, showing a warning or an error > would be an improvement. We could signal an error, yes. But it sounds too drastic to me. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 13 15:30:28 2025 Received: (at 76969) by debbugs.gnu.org; 13 Mar 2025 19:30:28 +0000 Received: from localhost ([127.0.0.1]:58231 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tsoGB-0008Kh-U9 for submit@debbugs.gnu.org; Thu, 13 Mar 2025 15:30:28 -0400 Received: from fout-a3-smtp.messagingengine.com ([103.168.172.146]:45813) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tsoG9-0008KJ-6w for 76969@debbugs.gnu.org; Thu, 13 Mar 2025 15:30:26 -0400 Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfout.phl.internal (Postfix) with ESMTP id F2B261383184; Thu, 13 Mar 2025 15:30:19 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-07.internal (MEProxy); Thu, 13 Mar 2025 15:30:19 -0400 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=fm3; t=1741894219; x=1741980619; bh=Y6QQx3mYKBzFImnZC5l6NqX1rh84QaQ+IsBF+AUpnZY=; b= yI9CY3bAgHjr+ZmbiBjJLHbT5xQ7kIqJokRw1zQcUWrFkdNiG78m39XVOxi6OdRX GQykaIVGcY8vwC2N3dipZINN+bgg5hgl9lIj2lhaIsIqUxN50CW3bes4nEJC0uuH l+hZM+bkbuC6FxGKF8wNu4qfCfy6INGZZ52oSXe8exO2xSrkQPtyp4BFcg7Bo5uu JTHMWjHP8rei+irAQufcEsJcDSdoEehURQsgG6KfOmpUCgqohnJVubVpvl/Fu5BW 75U2NgkFE27b49C0VxLr5plgtDLTUmRSJ7UcsECu4st/v/ycrH3k5V7sng28WCUW jKvRe5GfviumsxiEHpiuNA== 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=fm1; t=1741894219; x= 1741980619; bh=Y6QQx3mYKBzFImnZC5l6NqX1rh84QaQ+IsBF+AUpnZY=; b=j P7uMMzzmo+MbBzbGIt+I2hxWXkwxNQpaCIz5drkrPFHtMsXPrA82s4sS2DwxtyId NvKYoKdYjSaUS39wnxmZksfEbUfFE73KoQRWaxwRBikDJzRUcPtJT1puvD1lgoUp 9SFDO6JCMbLzNlgKbYaXFKqXlyQEAK4A/URnGXSG+AxRFrgHM9+SPgiRhTvRd65O CCQinwJIki9MRH8K8a/66B+RpDToa/2GJrG7HUPGWa1D04pRT/E76NcxCwj2WT9F tjzhyT4ggzFi70dUtUXBYAiLh/QO5m2N0Gb6PF4v1lpb89d2XR8M7YlWj0kIvCoI NfuYD2FGQGyKXkgmlPJMA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduvdekjeelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddt vdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovh druggvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieek ueeftddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphht thhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdroh hrghdprhgtphhtthhopeejieelieelseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp thhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 13 Mar 2025 15:30:18 -0400 (EDT) Message-ID: Date: Thu, 13 Mar 2025 21:30:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current To: Eli Zaretskii References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86wmct0yfj.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76969 Cc: Spencer Baugh , 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 13/03/2025 16:58, Eli Zaretskii wrote: >> Yes, I think it will be good to note that there are certain rare >> exceptions (when the buffer is the minibuffer or the sole other buffer), >> and that kill-buffer will skip killing them and simply return nil >> without complaint. > > OK, we can extend the doc string with these caveats. Great - at least being aware of those cases should help. >> And the consequences seem less severe, conceptually, than killing one of >> the exceptions mentioned above. The exception for threads seems to have >> been made as a matter of implementation convenience, so it's worth >> revisiting. > > If we want to kill a buffer that is the current buffer of some thread, > we must do the same thing we do when killing the buffer that is > current in the thread which calls kill-buffer: replace it with some > other buffer, if possible: > > /* Make this buffer not be current. Exit if it is the sole visible > buffer. */ > if (b == current_buffer) > { > tem = Fother_buffer (buffer, Qnil, Qnil); > Fset_buffer (tem); > if (b == current_buffer) > return Qnil; > } Makes sense, but it's probably not a good idea for threads. Same reason: unpredictability. If the direct kill-buffer call swaps the buffer under you, it's somewhat odd, but at least it's predictable and can be debugged. Having a different thread do that do your execution flow at a random time is quite another thing. >> To reiterate, having the buffer killed (and the associated thread with >> it) seems preferable - perhaps after allowing the thread to handle the >> attempt. > > You forget that the other thread (the one which uses the buffer as the > current) cannot do anything because it is blocked trying to take the > global lock, while this thread, the one which called kill-buffer, > runs. The only way to allow that thread to do anything would be to > defer to that thread to do the killing, and yield the global lock to > it so it could actually do that. But this requires infrastructure we > don't have, because we cannot currently yield to a specific thread. Yeah, I was imagining something like that. If it's not possible with the current infra, maybe leave a TODO? >> And/or if the killing does not happen, showing a warning or an error >> would be an improvement. > > We could signal an error, yes. But it sounds too drastic to me. Or a warning, or an entry in *Messages*, at least. Anything's better than silent noop. And you can't examine the thread's current buffer in Lisp, to find the conflicting thread another way from Lisp (e.g. for print-debugging). From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 13 16:16:56 2025 Received: (at 76969) by debbugs.gnu.org; 13 Mar 2025 20:16:56 +0000 Received: from localhost ([127.0.0.1]:58325 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tsoz9-0002NZ-S4 for submit@debbugs.gnu.org; Thu, 13 Mar 2025 16:16:56 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:35059) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tsoz6-0002NC-2B for 76969@debbugs.gnu.org; Thu, 13 Mar 2025 16:16:53 -0400 From: Spencer Baugh To: Dmitry Gutov Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current In-Reply-To: (Dmitry Gutov's message of "Thu, 13 Mar 2025 21:30:15 +0200") References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> Date: Thu, 13 Mar 2025 16:16:46 -0400 Message-ID: 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=1741897006; bh=oRfCObt+MNeufJMXKkurj0hnHxBf01tvenXvip8qCcI=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=ULCcR9hx46YjGi1oL+/t3BToATWV71bL1HDdTtT+5n/gEKIQvj0+MJdlStENRNbHn r6Bx+NIfiuUdn0olxkBuro9r7XckiGee7twk408BrXI5wu0NcYwwexYb0HkPJ/f68s b6+OnOPhVNR/SsUDMcvAqhq0KBQa4cB9bQl5a2j+hqSVqJBz517fPXcTp9V/HOQ3pX JvhSHuH+K1W5/dJRtHwjjcsaVP7m8ja+oRegEBChv7tuinunrzUO5k/4X/P/qY8KNS DzbDWilOWbnNoo4TLnu01+vHZ5se3g3VbO+/NwyOo1xKA3shK+56WtgovXmnj1/R6p wlUlP4n0NufzA== X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 76969 Cc: Eli Zaretskii , 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) Dmitry Gutov writes: > On 13/03/2025 16:58, Eli Zaretskii wrote: >>> And/or if the killing does not happen, showing a warning or an error >>> would be an improvement. >> We could signal an error, yes. But it sounds too drastic to me. > > Or a warning, or an entry in *Messages*, at least. Anything's better > than silent noop. And you can't examine the thread's current buffer in > Lisp, to find the conflicting thread another way from Lisp (e.g. for > print-debugging). Note that if you try kill a buffer which is the process-buffer of some process: - process-kill-buffer-query-function will query the user whether they want to proceed. - If the user decides to proceed, then the process in that buffer will simply be killed with SIGHUP. Perhaps we should do a similar thing for threads? - Add a new kill-buffer-query-functions which checks if the buffer being killed is the current-buffer of any threads, and if so, queries the user if they want to proceed. - If the user decides to proceed, then do something like killing the thread with SIGHUP. Probably call thread-signal on the thread. We'll still need to switch the thread's current-buffer to a new buffer, since the thread could choose to handle the signal and continue executing. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 13 16:30:49 2025 Received: (at 76969) by debbugs.gnu.org; 13 Mar 2025 20:30:49 +0000 Received: from localhost ([127.0.0.1]:58371 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tspCb-0003Hx-6I for submit@debbugs.gnu.org; Thu, 13 Mar 2025 16:30:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39140) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tspCY-0003Hf-GA for 76969@debbugs.gnu.org; Thu, 13 Mar 2025 16:30:47 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tspCQ-0002Xp-Ex; Thu, 13 Mar 2025 16:30:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=d3MXEdJzaHBxz6ya9vOPkThfCvlZlWrNhVXZtXo5Fg4=; b=ag6G71NKo4yx PE25BLd6SlIyehYfc5pezgBTuMWP3JKdySxxuetOvpLNMZEv2H0qXmgVTFHsR5fe5+YZ5Qdzwn4X8 QZug8bVfp+7iZfmaeEyKg0MjV469cNOydzkfMH90HmfxpP+RrwM7ERocC13asJ4fKlYJVJ12N+UKp qTFrG8dDAbfeOUmrv7ykmoDS/TslteRGFjdRk5ohdyQNtTQpOMNkVubW7CHy8M58ahDlTOd4EUuzA QHXvJZRydSzs4YSAkNCkIEZP3Vr6KhTHuuQx1Sc5Np0PdDEMQKXn7u6LI7Y7M0Y+nDuC01bUF9IIA u45BszZOY106rgo8HFBhIw==; Date: Thu, 13 Mar 2025 22:29:55 +0200 Message-Id: <86bju41xoc.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Thu, 13 Mar 2025 21:30:15 +0200) Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > Date: Thu, 13 Mar 2025 21:30:15 +0200 > Cc: 76969@debbugs.gnu.org, Spencer Baugh > From: Dmitry Gutov > > On 13/03/2025 16:58, Eli Zaretskii wrote: > > > If we want to kill a buffer that is the current buffer of some thread, > > we must do the same thing we do when killing the buffer that is > > current in the thread which calls kill-buffer: replace it with some > > other buffer, if possible: > > > > /* Make this buffer not be current. Exit if it is the sole visible > > buffer. */ > > if (b == current_buffer) > > { > > tem = Fother_buffer (buffer, Qnil, Qnil); > > Fset_buffer (tem); > > if (b == current_buffer) > > return Qnil; > > } > > Makes sense, but it's probably not a good idea for threads. Same reason: > unpredictability. > > If the direct kill-buffer call swaps the buffer under you, it's somewhat > odd, but at least it's predictable and can be debugged. Having a > different thread do that do your execution flow at a random time is > quite another thing. Suppose a process filter or sentinel, or a timer does that -- is that any different? should we forbid that? > >> And/or if the killing does not happen, showing a warning or an error > >> would be an improvement. > > > > We could signal an error, yes. But it sounds too drastic to me. > > Or a warning, or an entry in *Messages*, at least. Anything's better > than silent noop. And you can't examine the thread's current buffer in > Lisp, to find the conflicting thread another way from Lisp (e.g. for > print-debugging). I'd still prefer to kill the buffer, just more safely. I mean, how is this different from killing a buffer that is displayed in one or more windows? We do handle that. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 13 16:38:45 2025 Received: (at 76969) by debbugs.gnu.org; 13 Mar 2025 20:38:45 +0000 Received: from localhost ([127.0.0.1]:58404 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tspKG-0003kC-Rr for submit@debbugs.gnu.org; Thu, 13 Mar 2025 16:38:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57684) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tspKE-0003js-Ve for 76969@debbugs.gnu.org; Thu, 13 Mar 2025 16:38:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tspK7-0003HL-F3; Thu, 13 Mar 2025 16:38:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ovVBa/EIHyV+ZwoTly7xu0mgOh0TYjTXYghZLUvOKwQ=; b=NekNQdHeUHBB it8UEGMHnVf520oMEVQlVhz2bm5wvNf1775cqh5d7am8Ath0W8AyWxLy2Fvdk0BHHv+IUXF7D2U4K Nw7R75UMUdwgOT+fwX0MqNHNsGLTb3URj6r4vlzn1q7jzn56YyPHGjXMya/O3KAcI5NGS0JzaV5Db ieN2U2o/wqaBCMhEvbec89a13dINqrpuZ143U04/g314gU8lsQ9YepuEqzVihxSYMUjPEgU5MQsGQ LaVRxQkm2BnQjm/6xigJY40p5CTlJm5Xe6IZnOp3zjuYFZ6JeifdvWJH3XXGZd3gfKj/vZ2kiMZwc KTJ5G311cRBKLFSQWp8WFw==; Date: Thu, 13 Mar 2025 22:38:15 +0200 Message-Id: <868qp81xag.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Thu, 13 Mar 2025 16:16:46 -0400) Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76969 Cc: dmitry@gutov.dev, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: Eli Zaretskii , 76969@debbugs.gnu.org > Date: Thu, 13 Mar 2025 16:16:46 -0400 > > Note that if you try kill a buffer which is the process-buffer of some > process: > > - process-kill-buffer-query-function will query the user whether they > want to proceed. > > - If the user decides to proceed, then the process in that buffer will > simply be killed with SIGHUP. > > Perhaps we should do a similar thing for threads? That still leaves the issue of what to do if the user says to kill. The basic problem of being unable to leave a thread without a current-buffer still stands, and needs to be solved. > - Add a new kill-buffer-query-functions which checks if the buffer being > killed is the current-buffer of any threads, and if so, queries the > user if they want to proceed. > > - If the user decides to proceed, then do something like killing the > thread with SIGHUP. Probably call thread-signal on the thread. We'll > still need to switch the thread's current-buffer to a new buffer, > since the thread could choose to handle the signal and continue > executing. Same here: these measures don't solve the technical reason why killing buffers that are current in some other thread was disallowed. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 13 17:22:14 2025 Received: (at 76969) by debbugs.gnu.org; 13 Mar 2025 21:22:14 +0000 Received: from localhost ([127.0.0.1]:58536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tsq0M-0006Hm-Ad for submit@debbugs.gnu.org; Thu, 13 Mar 2025 17:22:14 -0400 Received: from fhigh-a7-smtp.messagingengine.com ([103.168.172.158]:54057) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tsq0J-0006HV-Ll for 76969@debbugs.gnu.org; Thu, 13 Mar 2025 17:22:12 -0400 Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfhigh.phl.internal (Postfix) with ESMTP id 234001140195; Thu, 13 Mar 2025 17:22:04 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Thu, 13 Mar 2025 17:22:04 -0400 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=fm3; t=1741900924; x=1741987324; bh=NLB+g9pXqQzVUgUSXyr8Vu1umBQenaa4KPvrUTURbhg=; b= MBwdSF0s1o5xKZZ4tnH16ycySGnpYxg5fOZxraLrVL4+YJm+cQxDNczB5Sh9KFJR Kprd/ilGfq70AgTBe4G/QdcVKjMHB4f3M6LS/wpt3+ARxutfjpODdWMtGbnlWLv2 e78UxHToWjaqRRlDZmv/Cts0q/OSW1t25mZsscvGhb4Bvg7IyuN8D59oymAN1vKb T4WNOVO8LQoyjjNiH7hBhd6h/KJ7ikRjKccHWUebkPwMMVdSZ3S3vWTS4iB+vo9G r5+F6QwfAvWqNNVDMnC2n0pF6wjXa3lzLLPhI6bCip755yusMwQ2ZXHCVUbokP53 Q6pdICYyswVk7SL0SDrTIw== 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=fm1; t=1741900924; x= 1741987324; bh=NLB+g9pXqQzVUgUSXyr8Vu1umBQenaa4KPvrUTURbhg=; b=T RkE/cKe7/pOcXvJyAa+srvVuPMjhD1eez4yX3N4S0IB5/aiFa7UiovIUYwtvGVbE 0V6BgjDBS/+Mgok5dJwUptm9kcKh9B5GuwZyxp4ATrXQC+kPPqg+klgOOQbzzLrD /VB3su2G1WMN209bZaAcNl/Y8swj9Zp+Iuh7KxoiddKRN7Gfuped50AR+g27z+7F zGB0qgvq/ZoVk9p2Vohb2P/jYPIUPsXpnnRRz9nzsARuRnRJs3P1gXZ1UgqmgQD6 SK/I9fdzwXfdhXwnD7ViBGtBUhKPO725U5X53wYtlDCxOWRm9UUm9pKNyKPNH8UF CfK9WQ82f8z636XTlhl2w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduvdeltdduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddt vdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovh druggvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieek ueeftddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphht thhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdroh hrghdprhgtphhtthhopeejieelieelseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp thhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 13 Mar 2025 17:22:02 -0400 (EDT) Message-ID: <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> Date: Thu, 13 Mar 2025 23:21:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current To: Eli Zaretskii References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86bju41xoc.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 13/03/2025 22:29, Eli Zaretskii wrote: >> If the direct kill-buffer call swaps the buffer under you, it's somewhat >> odd, but at least it's predictable and can be debugged. Having a >> different thread do that do your execution flow at a random time is >> quite another thing. > > Suppose a process filter or sentinel, or a timer does that -- is that > any different? should we forbid that? Yeah, I think a timer or a sentinel killing a non-"private" buffer would be a programmer error. Still, in that case the caller can compare the kill-buffer argument to current-buffer and see that they're equal - so print-debugging would still work (or edebug, etc). >>>> And/or if the killing does not happen, showing a warning or an error >>>> would be an improvement. >>> >>> We could signal an error, yes. But it sounds too drastic to me. >> >> Or a warning, or an entry in *Messages*, at least. Anything's better >> than silent noop. And you can't examine the thread's current buffer in >> Lisp, to find the conflicting thread another way from Lisp (e.g. for >> print-debugging). > > I'd still prefer to kill the buffer, just more safely. I mean, how is > this different from killing a buffer that is displayed in one or more > windows? We do handle that. Okay, how about Spencer's suggestion (maybe modulo the kill-buffer-query-functions part)? When we try to kill a buffer that is current to a thread, we first send a signal to that thread (to be handled async), then switch that thread's buffer to another (*). Do that check in all threads, then kill the buffer. This way the Lisp code running in there would be notified about the change - and probably crash right away unless it expects this specific error. Better than a silent change. (*) Though we should probably do that after and if all kill-buffer-query-functions have run with positive result. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 14 03:26:44 2025 Received: (at 76969) by debbugs.gnu.org; 14 Mar 2025 07:26:44 +0000 Received: from localhost ([127.0.0.1]:59894 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tszRL-0001go-VQ for submit@debbugs.gnu.org; Fri, 14 Mar 2025 03:26:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60404) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tszRJ-0001gZ-MU for 76969@debbugs.gnu.org; Fri, 14 Mar 2025 03:26:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tszRA-0005U2-DA; Fri, 14 Mar 2025 03:26:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=6jIV8gBATyLKuAv1Zhd7Egp07Lx4scQcG+4pgvAX7XI=; b=ABsUK6TRpBon ccElquAqPOs+t4FG0EQNQVXxhYtABaIdxcxyqUogg/zCHj9DTRYJQpzga5YXeJejHPqCnVb537yLc WNJo2Crs45onizkv0yJ64lgcMRkpl7/5vg2UCpMLRcmfuf4Az4Nr4iuLLYV+yrhaDcAAa4sH5hjkx 7xgIDVY8/VrgPvP+S6xKUu/kvklE56hpZQyKHRsBa901EOmV0UaRQCU6DjkmAT/jz8mef++geMYZ5 86dnHckxnqlrHN7UXoy5yZ19xnp8dWiTo//3wGs9427/sY8g3+kYsHdKb7SofGP4o7W8g/Dw1luJ4 l0y8+kLt3Ntr6ysMGQ5z2A==; Date: Fri, 14 Mar 2025 09:26:03 +0200 Message-Id: <86zfhoysxg.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> (message from Dmitry Gutov on Thu, 13 Mar 2025 23:21:59 +0200) Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > Date: Thu, 13 Mar 2025 23:21:59 +0200 > Cc: 76969@debbugs.gnu.org, sbaugh@janestreet.com > From: Dmitry Gutov > > On 13/03/2025 22:29, Eli Zaretskii wrote: > > >> If the direct kill-buffer call swaps the buffer under you, it's somewhat > >> odd, but at least it's predictable and can be debugged. Having a > >> different thread do that do your execution flow at a random time is > >> quite another thing. > > > > Suppose a process filter or sentinel, or a timer does that -- is that > > any different? should we forbid that? > > Yeah, I think a timer or a sentinel killing a non-"private" buffer would > be a programmer error. Still, in that case the caller can compare the > kill-buffer argument to current-buffer and see that they're equal - so > print-debugging would still work (or edebug, etc). If it's important, we could provide a thread-buffer function to return the current buffer of a thread. Should be easy to implement. > >>>> And/or if the killing does not happen, showing a warning or an error > >>>> would be an improvement. > >>> > >>> We could signal an error, yes. But it sounds too drastic to me. > >> > >> Or a warning, or an entry in *Messages*, at least. Anything's better > >> than silent noop. And you can't examine the thread's current buffer in > >> Lisp, to find the conflicting thread another way from Lisp (e.g. for > >> print-debugging). > > > > I'd still prefer to kill the buffer, just more safely. I mean, how is > > this different from killing a buffer that is displayed in one or more > > windows? We do handle that. > > Okay, how about Spencer's suggestion (maybe modulo the > kill-buffer-query-functions part)? When we try to kill a buffer that is > current to a thread, we first send a signal to that thread (to be > handled async), then switch that thread's buffer to another (*). Do that > check in all threads, then kill the buffer. If you signal a thread that wasn't prepared to catch the signal, the thread will terminate. How many thread functions out there are prepared to catch signals? This would require every thread function to be wrapped in condition-case with a non-trivial handler. And what do we expect the handler to do? probably what the loop in kill-buffer that replaces the current buffer will do anyway, or perhaps just quit in a more orderly fashion? Maybe this could be an optional feature, though. That is, the make-thread call could accept an additional optional argument to indicate that this thread would like to be signaled if its current buffer is ever killed. Patches welcome. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 14 21:28:04 2025 Received: (at 76969) by debbugs.gnu.org; 15 Mar 2025 01:28:04 +0000 Received: from localhost ([127.0.0.1]:36933 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ttGJo-0002pi-3I for submit@debbugs.gnu.org; Fri, 14 Mar 2025 21:28:04 -0400 Received: from fhigh-a8-smtp.messagingengine.com ([103.168.172.159]:46157) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ttGJl-0002p8-UU for 76969@debbugs.gnu.org; Fri, 14 Mar 2025 21:28:02 -0400 Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfhigh.phl.internal (Postfix) with ESMTP id C1D2B11400AD; Fri, 14 Mar 2025 21:27:56 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-07.internal (MEProxy); Fri, 14 Mar 2025 21:27:56 -0400 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=fm3; t=1742002076; x=1742088476; bh=yNKFGJ2M6SI01Kzov9M0CECIbs8c+jsQXa/oXvWdfaQ=; b= HRhsLaH625jIhO37iung07lpz7g9ns7usNQuM7MwRfYn7qDi7MJJgQ6KQhsaAXN6 PU5WUoeK1muvQ5eRy3+NNhCNjx7O2SG1dT7Llgx/JIJ4bPXXOxlqc3dO/A8W7ljs P6D2RMkCMUS6XV1m7KOR40HePOgblLdTjIDfPPjaR+GPN8E1TouI90VKm7MrfIxC 0RMOaZe/7CET8hayQbmQCjlw/Ad0UhiyW58xvj2db4wunjzkKZE9Z1De64ewXLrE 4lhg3iX1aQYDgLKDTcB7s2+LdJQLykC2KiGaloXiYALyQyNuLVhBOujbmqVYs/hu gPRXCjqRtQgHGngnPKVN/g== 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=fm1; t=1742002076; x= 1742088476; bh=yNKFGJ2M6SI01Kzov9M0CECIbs8c+jsQXa/oXvWdfaQ=; b=Z V6VbsFRedOm+hzHxcRmRka9Oz3IwbicSUXc28eOFT18F8ieC/lkr912qYB4+H48l P/AgEASP7Gsxj6xtOVvXzJbMfHpQSuCvLWU5nXJ6dCtj0sQN4lqOqLX5myoBiEGm wAEHHOuKerAtn2zhrjkyL3LdcAh5r06/BRBz/7yLMqHk6B0FwyEqrgIHczNxayjD qemiU1MgBzKZMw+4qUn5eZH2LJTqqcWXVlogSqfUdp8VgqZujPMXhiBKngGofvOU vs3vJ3nfTafMV5lahbM1ujQByboztt3xAWZ+wODKt5aL38ZiK+Pg2O1YCnW2bs7N nWC/6f8zrP1vR9aQJcclg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddufedvfeelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddt vdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovh druggvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieek ueeftddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphht thhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdroh hrghdprhgtphhtthhopeejieelieelseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp thhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 14 Mar 2025 21:27:54 -0400 (EDT) Message-ID: <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> Date: Sat, 15 Mar 2025 03:27:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current To: Eli Zaretskii References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86zfhoysxg.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 14/03/2025 09:26, Eli Zaretskii wrote: >>> I'd still prefer to kill the buffer, just more safely. I mean, how is >>> this different from killing a buffer that is displayed in one or more >>> windows? We do handle that. >> >> Okay, how about Spencer's suggestion (maybe modulo the >> kill-buffer-query-functions part)? When we try to kill a buffer that is >> current to a thread, we first send a signal to that thread (to be >> handled async), then switch that thread's buffer to another (*). Do that >> check in all threads, then kill the buffer. > > If you signal a thread that wasn't prepared to catch the signal, the > thread will terminate. I think that is fine: terminate if the thread is not prepared to handle a buffer switch, but also allow it to handle it. > How many thread functions out there are > prepared to catch signals? This would require every thread function > to be wrapped in condition-case with a non-trivial handler. IME that is already a requirement - we don't have other straightforward ways to make sure the thread's code doesn't error, and or notifying the user otherwise. No automatic printing of such errors. thread-join doesn't raise a signal if the thread ended with a error either (which seems like a standard in other languages that I've worked with). More importantly, having a thread die seems safer than forcing an unexpected buffer change on it - this can lead to visual effects being applied to a wrong buffer, or more importantly, to data loss. > And what > do we expect the handler to do? probably what the loop in kill-buffer > that replaces the current buffer will do anyway, or perhaps just quit > in a more orderly fashion? Some parts of the function might actually be safe against buffer change (if the important context/data had been captured) - e.g. if the function created a temp buffer later anyway. Some parts couldn't handle it, but an error handled would be the place to perform orderly cleanup. > Maybe this could be an optional feature, though. That is, the > make-thread call could accept an additional optional argument to > indicate that this thread would like to be signaled if its current > buffer is ever killed. And I guess otherwise the buffer wouldn't be allowed to be killed? From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 15 05:30:50 2025 Received: (at 76969) by debbugs.gnu.org; 15 Mar 2025 09:30:50 +0000 Received: from localhost ([127.0.0.1]:38835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ttNr0-0000Jh-2h for submit@debbugs.gnu.org; Sat, 15 Mar 2025 05:30:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40290) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ttNqx-0000JS-Se for 76969@debbugs.gnu.org; Sat, 15 Mar 2025 05:30:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ttNqr-0001Uj-NL; Sat, 15 Mar 2025 05:30:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=4TcWjvMayCT3MsYTD+v+QtcwxK0FZ1oHEQZal0bu8X4=; b=DkYzQAHnKFvL ncY6rbxTl0IE8L7k0MKscIFtgDwLd7IkW/2k7QI3KgpoY2Oo9jaWLB0sKiuYnjP2EewPDkiYmsyYc tk+xvnL4PKnUPsy1p1vd1p16XdKuM5b6hG0WxpmVcbhYZbChBmwjEnwfYOV4AH9HtKUuGRo6ZF/wU /g/rlchTOXqBi8v4kSudDrqLG273ckad8rgrtD0OfTpPa0sb2aMIJO0fiu59cDttuFuhmfol7WQnJ pjyaxgPfDX4Mfjpbmojq+gpjYdy0WzfeaA83osdj2T3dzWOJpfZcluCHGRypfqEXOtVsPzHCmuX9r REqWNQOf23UgDrh0hT1AoQ==; Date: Sat, 15 Mar 2025 11:30:31 +0200 Message-Id: <86o6y2y72g.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> (message from Dmitry Gutov on Sat, 15 Mar 2025 03:27:52 +0200) Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > Date: Sat, 15 Mar 2025 03:27:52 +0200 > Cc: 76969@debbugs.gnu.org, sbaugh@janestreet.com > From: Dmitry Gutov > > On 14/03/2025 09:26, Eli Zaretskii wrote: > > > If you signal a thread that wasn't prepared to catch the signal, the > > thread will terminate. > > I think that is fine: terminate if the thread is not prepared to handle > a buffer switch, but also allow it to handle it. I think you only have in mind threads whose function is processing the buffer that will be killed. But threads can do other jobs, including jobs which are utterly unrelated to the current buffer, in which case terminating them is too drastic and unjustified. > > How many thread functions out there are > > prepared to catch signals? This would require every thread function > > to be wrapped in condition-case with a non-trivial handler. > > IME that is already a requirement - we don't have other straightforward > ways to make sure the thread's code doesn't error, and or notifying the > user otherwise. No automatic printing of such errors. thread-join > doesn't raise a signal if the thread ended with a error either (which > seems like a standard in other languages that I've worked with). Having a signal delivered from another thread is unusual, so saying it's a requirement is IMO far-fetched. It's like saying that every function or command should protect itself from quitting by the user. > More importantly, having a thread die seems safer than forcing an > unexpected buffer change on it - this can lead to visual effects being > applied to a wrong buffer, or more importantly, to data loss. You again are thinking about only a specific class of thread functions. Compare this with killing a buffer shown in the selected window and in some other windows, and draw your conclusions from the similarity of these two situations. > > Maybe this could be an optional feature, though. That is, the > > make-thread call could accept an additional optional argument to > > indicate that this thread would like to be signaled if its current > > buffer is ever killed. > > And I guess otherwise the buffer wouldn't be allowed to be killed? I meant to kill it in any case. If that ruins the thread's job, it would be the same programmatic error as when a buffer is killed by a timer. We could also have a buffer-local variable which prevents buffer from being killed. A thread which cannot allow its current buffer to be killed could then set this variable non-nil while the processing which requires that is in progress. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 15 09:55:14 2025 Received: (at 76969) by debbugs.gnu.org; 15 Mar 2025 13:55:14 +0000 Received: from localhost ([127.0.0.1]:39971 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ttRyr-0004wk-Ks for submit@debbugs.gnu.org; Sat, 15 Mar 2025 09:55:14 -0400 Received: from fout-a6-smtp.messagingengine.com ([103.168.172.149]:50213) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ttRyn-0004rz-Pp for 76969@debbugs.gnu.org; Sat, 15 Mar 2025 09:55:11 -0400 Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfout.phl.internal (Postfix) with ESMTP id 9E07C13832AA; Sat, 15 Mar 2025 09:55:03 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Sat, 15 Mar 2025 09:55:03 -0400 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=fm3; t=1742046903; x=1742133303; bh=4Dh9/GXXFik81wk453kyw3YkNYtRpsnoXwF9/it6DSY=; b= YRG/jEu0P1QK2wKRwSRFkzoZmD/HVbWc7Zbv/RrJMhp3Z84hXwWdfCaH9Qryo+ye fy6iPJGDIlVnjNsvWbyXHQzvsDVwcL+LtAAbCMDk3vR/m8s4SCDY13d+cEnAbIy0 2GqVgPUMApQpL+S2Akw0XjqX62yuXq4G6NcJe/f7ZLvHNxTYGif42io3LUM4AdHX K0anKE+iukcSHBMXHcoEkkSvJxAgN7Zoh6PmGbGclUFkqk0IjK8/QhO6EfBWFhZm 4cfSzUSLpbU7to87CBCIsbjywFpGlRH+s66ySX8oRAVE0i3uQ8zsKQatI6HL/0m9 B5S6gMjMSqtOnL8IUv4PFg== 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=fm1; t=1742046903; x= 1742133303; bh=4Dh9/GXXFik81wk453kyw3YkNYtRpsnoXwF9/it6DSY=; b=k mSsaR2b6EhKvFbTNlz3RDdq42fwv/Ypfy73OGQnJLzyiZt3RVPqsJdY+sqAj3rk+ jdS5qUHkGee7cVmd3cIV2me31PNnU8x53WBm8Sxj09YB75GJVkguJGFn4D2lozr9 ihute/0Hr5k7UxMeiKFC25jz7l9mUsTESWDAFdo0GuVr1synb+ntyEJreuhDgX73 c7V9PMCjBs/eHEOtWc7Kv3gYt8BwQT6i1YjlCHAVxixqC3icCPKLRi6uFZUzGAN4 EKFMY5LZZzoYdg9DGb9yYYtxNMulb41PKIccJBOSzGzSe7D4+g5p30lV6foIhOOe iq8lJxhiCRNygrO5rJpfA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddufeefkeelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddt vdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovh druggvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieek ueeftddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphht thhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdroh hrghdprhgtphhtthhopeejieelieelseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp thhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 15 Mar 2025 09:55:02 -0400 (EDT) Message-ID: Date: Sat, 15 Mar 2025 15:55:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current To: Eli Zaretskii References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86o6y2y72g.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 15/03/2025 11:30, Eli Zaretskii wrote: >> Date: Sat, 15 Mar 2025 03:27:52 +0200 >> Cc: 76969@debbugs.gnu.org, sbaugh@janestreet.com >> From: Dmitry Gutov >> >> On 14/03/2025 09:26, Eli Zaretskii wrote: >> >>> If you signal a thread that wasn't prepared to catch the signal, the >>> thread will terminate. >> >> I think that is fine: terminate if the thread is not prepared to handle >> a buffer switch, but also allow it to handle it. > > I think you only have in mind threads whose function is processing the > buffer that will be killed. But threads can do other jobs, including > jobs which are utterly unrelated to the current buffer, in which case > terminating them is too drastic and unjustified. My view is that there would be a bunch of threads running concurrently, most of them "harmless" - but there would be some that modify buffer contents. Having the buffer switched under them could lead to data loss in another buffer which happened to be next in the list, with the changes quite possibly saved to disk. We can't really distinguish between these kinds of threads from the outside, so the general model would need to err on the side of safety. >>> How many thread functions out there are >>> prepared to catch signals? This would require every thread function >>> to be wrapped in condition-case with a non-trivial handler. >> >> IME that is already a requirement - we don't have other straightforward >> ways to make sure the thread's code doesn't error, and or notifying the >> user otherwise. No automatic printing of such errors. thread-join >> doesn't raise a signal if the thread ended with a error either (which >> seems like a standard in other languages that I've worked with). > > Having a signal delivered from another thread is unusual, so saying > it's a requirement is IMO far-fetched. It's like saying that every > function or command should protect itself from quitting by the user. Interactive commands, timers and functions in the main thread go through the usual error handling - which at least results in the error being printed to Messages. More, if the debugger is toggled on. >> More importantly, having a thread die seems safer than forcing an >> unexpected buffer change on it - this can lead to visual effects being >> applied to a wrong buffer, or more importantly, to data loss. > > You again are thinking about only a specific class of thread > functions. Compare this with killing a buffer shown in the selected > window and in some other windows, and draw your conclusions from the > similarity of these two situations. Not sure what thread function you're thinking of in this case. >>> Maybe this could be an optional feature, though. That is, the >>> make-thread call could accept an additional optional argument to >>> indicate that this thread would like to be signaled if its current >>> buffer is ever killed. >> >> And I guess otherwise the buffer wouldn't be allowed to be killed? > > I meant to kill it in any case. If that ruins the thread's job, it > would be the same programmatic error as when a buffer is killed by a > timer. > > We could also have a buffer-local variable which prevents buffer from > being killed. A thread which cannot allow its current buffer to be > killed could then set this variable non-nil while the processing which > requires that is in progress. It might slightly alter the thread's job, in an unpredictable way - many Lisp functions depend on buffer variables, and switching the current buffer from under them would switch those values unpredictably too. I'm not sure an average Lisp coder dabbling into threads would anticipate those kind of problems in advance. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 15 10:06:54 2025 Received: (at 76969) by debbugs.gnu.org; 15 Mar 2025 14:06:54 +0000 Received: from localhost ([127.0.0.1]:42973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ttSA8-00071F-EJ for submit@debbugs.gnu.org; Sat, 15 Mar 2025 10:06:53 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39124) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ttSA1-0006zJ-LI for 76969@debbugs.gnu.org; Sat, 15 Mar 2025 10:06:49 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ttS9u-0001Oq-97; Sat, 15 Mar 2025 10:06:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=aFB7Y/ahGW0nZZA6mu9lNAXpzMbWqxUerT4nRSoet7I=; b=e973ncCtbKE+ azKgF09dCmyCYU13mmGRopg9Z6St4VeHFx17YkhWiYwbJLcB8Bk9O4T7I4pAGbvt7QyxX7c84QcJt eofBKnO8pHyYj1aWO2IXkUbjBuCcid0MsfyM2Dn8/4rrrQvV3lYmel3ZbkZ4uS/pzvGZMK2DrObOv ArUchKKf5oa7fHerOHtwL+l8QjYT1du9VaNOHQIwapEJ39jfZIPM69d9JmBG3MCGNN/Ew3pSNRJGF BFsAMW5eX8c+LX98KiLyLShYz2VKKUWLzVXcIaeJQj0T8E5SMvlxJiVZIt7UyJeY15/K0uNeZsP2N M7eq+o7y/hSTQFPhOsA1JA==; Date: Sat, 15 Mar 2025 16:06:31 +0200 Message-Id: <868qp6wfq0.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Sat, 15 Mar 2025 15:55:00 +0200) Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > Date: Sat, 15 Mar 2025 15:55:00 +0200 > Cc: 76969@debbugs.gnu.org, sbaugh@janestreet.com > From: Dmitry Gutov > > On 15/03/2025 11:30, Eli Zaretskii wrote: > >> Date: Sat, 15 Mar 2025 03:27:52 +0200 > >> Cc: 76969@debbugs.gnu.org, sbaugh@janestreet.com > >> From: Dmitry Gutov > >> > >> On 14/03/2025 09:26, Eli Zaretskii wrote: > >> > >>> If you signal a thread that wasn't prepared to catch the signal, the > >>> thread will terminate. > >> > >> I think that is fine: terminate if the thread is not prepared to handle > >> a buffer switch, but also allow it to handle it. > > > > I think you only have in mind threads whose function is processing the > > buffer that will be killed. But threads can do other jobs, including > > jobs which are utterly unrelated to the current buffer, in which case > > terminating them is too drastic and unjustified. > > My view is that there would be a bunch of threads running concurrently, > most of them "harmless" - but there would be some that modify buffer > contents. Having the buffer switched under them could lead to data loss > in another buffer which happened to be next in the list, with the > changes quite possibly saved to disk. Yes. My point is that terminating each such thread because its current buffer was killed might be overkill for threads which don't care about their current-buffer. > We can't really distinguish between these kinds of threads from the > outside, so the general model would need to err on the side of safety. The side of safety in my book is not to kill the buffer. You suggested instead to signal the thread, which would terminate it, and I consider that not erring on the side of safety. > >> More importantly, having a thread die seems safer than forcing an > >> unexpected buffer change on it - this can lead to visual effects being > >> applied to a wrong buffer, or more importantly, to data loss. > > > > You again are thinking about only a specific class of thread > > functions. Compare this with killing a buffer shown in the selected > > window and in some other windows, and draw your conclusions from the > > similarity of these two situations. > > Not sure what thread function you're thinking of in this case. In this analogy, showing buffers is that "thread function". > > We could also have a buffer-local variable which prevents buffer from > > being killed. A thread which cannot allow its current buffer to be > > killed could then set this variable non-nil while the processing which > > requires that is in progress. > > It might slightly alter the thread's job, in an unpredictable way - many > Lisp functions depend on buffer variables, and switching the current > buffer from under them would switch those values unpredictably too. > > I'm not sure an average Lisp coder dabbling into threads would > anticipate those kind of problems in advance. I cannot connect your response with my suggestion to introduce a new buffer-local variable which, if non-nil, would prevent the buffer from being killed if it's the current-buffer of some thread. Perhaps there's some kind of misunderstanding. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 15 19:29:16 2025 Received: (at 76969) by debbugs.gnu.org; 15 Mar 2025 23:29:16 +0000 Received: from localhost ([127.0.0.1]:43997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ttawN-0000Ca-Fx for submit@debbugs.gnu.org; Sat, 15 Mar 2025 19:29:16 -0400 Received: from fout-b3-smtp.messagingengine.com ([202.12.124.146]:47217) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ttawI-0000Bz-Fd for 76969@debbugs.gnu.org; Sat, 15 Mar 2025 19:29:12 -0400 Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfout.stl.internal (Postfix) with ESMTP id A6FA1114012E; Sat, 15 Mar 2025 19:29:04 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Sat, 15 Mar 2025 19:29:04 -0400 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=fm3; t=1742081344; x=1742167744; bh=4nrsWfAkr51UkBdzPwuBryrr1ZIulBzzRKy6gHlWndg=; b= h4cY4XQGlsedwIq8rk+L00j8mXzyLSsrfeQGDZbHxSjYypCgUCrnfoa8aa7kxG+B il00aHuDVc1NGtSIt2GoIMi2Ec1pUW2glJwKPuFXyoZ9OUMuB7VylHPW26AXNHKB MYeushqRWmIzZcA8+M+JG2BKo1/7QFtnksnR5ueJlC1eMX2VoTxJcTiBlCi4dG1I Susu7thAuA84zKXHmtUIEmBR/1l9a4JT6kIjLaaS4TsDr6JVUgAyjJuhsUE5llgd h8AUKXBseG4hNE+cqu+h9wDxr3eaRQpdPzoeOAlvA4DQEjaDxWI+UkNtWuCfw3fm XzDtfHQA8lKhUgLrxeuLuw== 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=fm1; t=1742081344; x= 1742167744; bh=4nrsWfAkr51UkBdzPwuBryrr1ZIulBzzRKy6gHlWndg=; b=C Xe1lSCWNJgdIUexXMAsE+gZMc1TO/pTNxUrrgKHdBLPmreLkrv3KmCw5BiNCK2FQ cnlW7cE6wK1z883FWg5Z9yVds8tRtWMHsEC2OmB+XkFOp+QK0MbjcMRqDwYz2eFS z4l/t/ZgJdxd2FwZnjjZEwKd1aE0q4/oll3u3jGj4XLsNlR78dCOybux7NrKTWso 9uJ84SalQC69Pysm73X5zcUFVPRbG4MWXUMbKSOoXZB/EcM0u9w2YuWsgvYfKTgp zgQxC1qQh+3ZVOE1hFEl6rub92JkzOVHXkGeIHN5tLUWFOm1/SSvKqSlp2e94st9 ce2uYglxgig5ifA/QBINg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddufeehtdegucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddt vdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovh druggvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieek ueeftddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphht thhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdroh hrghdprhgtphhtthhopeejieelieelseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp thhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 15 Mar 2025 19:29:03 -0400 (EDT) Message-ID: <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> Date: Sun, 16 Mar 2025 01:29:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current To: Eli Zaretskii References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <868qp6wfq0.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 15/03/2025 16:06, Eli Zaretskii wrote: >> My view is that there would be a bunch of threads running concurrently, >> most of them "harmless" - but there would be some that modify buffer >> contents. Having the buffer switched under them could lead to data loss >> in another buffer which happened to be next in the list, with the >> changes quite possibly saved to disk. > > Yes. My point is that terminating each such thread because its > current buffer was killed might be overkill for threads which don't > care about their current-buffer. I wonder if the set of functions which behave safely under such conditions is large enough for this to be the default. >> We can't really distinguish between these kinds of threads from the >> outside, so the general model would need to err on the side of safety. > > The side of safety in my book is not to kill the buffer. You > suggested instead to signal the thread, which would terminate it, and > I consider that not erring on the side of safety. Okay... then by default we will not kill the buffer, but allow threads to opt into allowing the buffer to be killed, preceded by a signal? That sounds safe enough. But the downside is we retain the current issue, right? As described in the original report. If only some threads opt into a different behavior, in general things stay the same. >>>> More importantly, having a thread die seems safer than forcing an >>>> unexpected buffer change on it - this can lead to visual effects being >>>> applied to a wrong buffer, or more importantly, to data loss. >>> >>> You again are thinking about only a specific class of thread >>> functions. Compare this with killing a buffer shown in the selected >>> window and in some other windows, and draw your conclusions from the >>> similarity of these two situations. >> >> Not sure what thread function you're thinking of in this case. > > In this analogy, showing buffers is that "thread function". Okay. So take just a function that is going to display a buffer. If the buffer is killed, wouldn't it be better for the >>> We could also have a buffer-local variable which prevents buffer from >>> being killed. A thread which cannot allow its current buffer to be >>> killed could then set this variable non-nil while the processing which >>> requires that is in progress. >> >> It might slightly alter the thread's job, in an unpredictable way - many >> Lisp functions depend on buffer variables, and switching the current >> buffer from under them would switch those values unpredictably too. >> >> I'm not sure an average Lisp coder dabbling into threads would >> anticipate those kind of problems in advance. > > I cannot connect your response with my suggestion to introduce a new > buffer-local variable which, if non-nil, would prevent the buffer from > being killed if it's the current-buffer of some thread. Perhaps > there's some kind of misunderstanding. I was unclear if you think it's better to always kill the buffer, or to have that behavior opt-in. If the buffer is killed, though, I believe it is better to signal its threads. Having the buffer substituted can easily get unnoticed, and would be hard to debug. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 16 02:07:36 2025 Received: (at 76969) by debbugs.gnu.org; 16 Mar 2025 06:07:37 +0000 Received: from localhost ([127.0.0.1]:44973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tth9r-0000p8-FF for submit@debbugs.gnu.org; Sun, 16 Mar 2025 02:07:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48028) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tth9o-0000no-Sj for 76969@debbugs.gnu.org; Sun, 16 Mar 2025 02:07:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tth9i-0005AK-Ik; Sun, 16 Mar 2025 02:07:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=WXCGqt39NctAFCAVCEPNcYgF5aOJmjFjMyfcB1K9qhM=; b=Mtiq20OSYSkG Cdj53XJ2CSYxCoLQ61GvGQrkxAT1v780+px53Jyk9qJupD5MYMlSm8kX19hbxZWutnmyc5PeBD4o7 SXMDlP+ED0akm67d8lmEZnHkBsk7HgfiOdsXlEAAYe6rTQfu1RCKg81ryh/61lDTvZJeRtILwExgw HKuZ5YfLjt4V1opZLXbaeVe49Z2LKIaR7P0hmGAvC/YOWFA2nlCNCpVvVwKJbbie+1F6lEUlKJTSQ egJhsMIeGdmTzbJCZjrytsrHnQCnjUeKzxW6WXmQ6lgQTWdN4Mt01qYTezIUxqYbakh0FRJjmQlcQ AOnQS+tLNkUyX4HQUpjJAQ==; Date: Sun, 16 Mar 2025 08:07:18 +0200 Message-Id: <86ldt5v78p.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> (message from Dmitry Gutov on Sun, 16 Mar 2025 01:29:00 +0200) Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > Date: Sun, 16 Mar 2025 01:29:00 +0200 > Cc: 76969@debbugs.gnu.org, sbaugh@janestreet.com > From: Dmitry Gutov > > On 15/03/2025 16:06, Eli Zaretskii wrote: > > >> My view is that there would be a bunch of threads running concurrently, > >> most of them "harmless" - but there would be some that modify buffer > >> contents. Having the buffer switched under them could lead to data loss > >> in another buffer which happened to be next in the list, with the > >> changes quite possibly saved to disk. > > > > Yes. My point is that terminating each such thread because its > > current buffer was killed might be overkill for threads which don't > > care about their current-buffer. > > I wonder if the set of functions which behave safely under such > conditions is large enough for this to be the default. If someone would like to make a survey of use patterns of Lisp threads, I think it will be useful in more than one way. > >> We can't really distinguish between these kinds of threads from the > >> outside, so the general model would need to err on the side of safety. > > > > The side of safety in my book is not to kill the buffer. You > > suggested instead to signal the thread, which would terminate it, and > > I consider that not erring on the side of safety. > > Okay... then by default we will not kill the buffer, but allow threads > to opt into allowing the buffer to be killed, preceded by a signal? > > That sounds safe enough. I actually thought the other way around: kill the buffer and deliver the signal, unless a special buffer-local variable is non-nil. > But the downside is we retain the current issue, right? As described in > the original report. With your default, yes. OTOH, the original report didn't explain why not killing the buffer is a problem. In general, any Lisp program that calls kill-buffer should be prepared to deal with the fact that the buffer might not be killed, due to any of the possible reasons which prevent that already, even if other threads are no involved. > > If only some threads opt into a different behavior, in general things > stay the same. > > >>>> More importantly, having a thread die seems safer than forcing an > >>>> unexpected buffer change on it - this can lead to visual effects being > >>>> applied to a wrong buffer, or more importantly, to data loss. > >>> > >>> You again are thinking about only a specific class of thread > >>> functions. Compare this with killing a buffer shown in the selected > >>> window and in some other windows, and draw your conclusions from the > >>> similarity of these two situations. > >> > >> Not sure what thread function you're thinking of in this case. > > > > In this analogy, showing buffers is that "thread function". > > Okay. So take just a function that is going to display a buffer. If the > buffer is killed, wouldn't it be better for the This sentence seems to be unfinished. > I was unclear if you think it's better to always kill the buffer, or to > have that behavior opt-in. That's because I don't yet have a firm opinion. And to some extent that depends on the optional features we will implement: . is signal always delivered or only to threads which said they want it? . do we add a buffer-local dont-ever-kill-my-buffer variable? > If the buffer is killed, though, I believe it is better to signal its > threads. Having the buffer substituted can easily get unnoticed, and > would be hard to debug. And I tend to prefer leaving this to the Lisp program which starts the thread, via an additional argument to make-thread. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 17 15:17:18 2025 Received: (at 76969) by debbugs.gnu.org; 17 Mar 2025 19:17:19 +0000 Received: from localhost ([127.0.0.1]:60969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tuFxe-0005iL-Ap for submit@debbugs.gnu.org; Mon, 17 Mar 2025 15:17:18 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:54155) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tuFxb-0005ej-Js for 76969@debbugs.gnu.org; Mon, 17 Mar 2025 15:17:16 -0400 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current In-Reply-To: <86ldt5v78p.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 16 Mar 2025 08:07:18 +0200") References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> Date: Mon, 17 Mar 2025 15:17:09 -0400 Message-ID: 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=1742239029; bh=Cs8QecF7QnT8j6IgTmeih48wrfUh5Xp+6v85JHa6DX0=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=PuYWQpHihO+TpZSOADHFp3o1Zf6w6qsc3Ckgn5RC/5cXJHy6lAirOgyCHYWkQwJRM ZkUiM0p2D4d79ujb1XANiIJ/YY+fKR3xZnm9mpqVbjRSyhm1oLN/QhAD0sZzQZzyNZ OxccbCmhtTyemGUATw4spzXfQFWFm6PbhodwhzoREJnIi8A7Ui/giQ0pgSPj5r7Ml5 k6BBt3ZzCp0es1dL+Kh7KcWyyciSdZUpgcvEJ4T4vaB7hgYOVjszt01f/s9IFAmB/H 6ZqzAwtie7Thz/nFHBfDco4imHgx0L/zL1Y1Wawi9wuPVTupIb/91QhsVzMe91Yhnx 13y4PedG17eow== X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 76969 Cc: Dmitry Gutov , 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) Eli Zaretskii writes: >> Date: Sun, 16 Mar 2025 01:29:00 +0200 >> Cc: 76969@debbugs.gnu.org, sbaugh@janestreet.com >> From: Dmitry Gutov >> >> On 15/03/2025 16:06, Eli Zaretskii wrote: >> >> >> My view is that there would be a bunch of threads running concurrently, >> >> most of them "harmless" - but there would be some that modify buffer >> >> contents. Having the buffer switched under them could lead to data loss >> >> in another buffer which happened to be next in the list, with the >> >> changes quite possibly saved to disk. >> > >> > Yes. My point is that terminating each such thread because its >> > current buffer was killed might be overkill for threads which don't >> > care about their current-buffer. >> >> I wonder if the set of functions which behave safely under such >> conditions is large enough for this to be the default. > > If someone would like to make a survey of use patterns of Lisp > threads, I think it will be useful in more than one way. > >> >> We can't really distinguish between these kinds of threads from the >> >> outside, so the general model would need to err on the side of safety. >> > >> > The side of safety in my book is not to kill the buffer. You >> > suggested instead to signal the thread, which would terminate it, and >> > I consider that not erring on the side of safety. >> >> Okay... then by default we will not kill the buffer, but allow threads >> to opt into allowing the buffer to be killed, preceded by a signal? >> >> That sounds safe enough. > > I actually thought the other way around: kill the buffer and deliver > the signal, unless a special buffer-local variable is non-nil. I agree. I think "kill the buffer and deliver the signal" makes sense as a default behavior, suppressed when a special buffer-local is non-nil. I think then we wouldn't need a new argument for make-thread, because threads which care about suppressing kill-buffer can simply set this new buffer-local variable. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 17 15:41:32 2025 Received: (at 76969) by debbugs.gnu.org; 17 Mar 2025 19:41:32 +0000 Received: from localhost ([127.0.0.1]:32803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tuGL6-0000Ey-8H for submit@debbugs.gnu.org; Mon, 17 Mar 2025 15:41:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60102) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tuGL2-0000Dt-U2 for 76969@debbugs.gnu.org; Mon, 17 Mar 2025 15:41:29 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tuGKw-0002y2-O3; Mon, 17 Mar 2025 15:41:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=uYXy2t+THz8bAFPSsICBKYSlvSF6cs09RWL5aegEULc=; b=RHJ8E4NfjuTl LKQxddhmzCyjRspBz0g3Q0KtkvMnaR0Oo7tg2oxNPiI+I2uVNseHQIRWt9bQdrxIovGoXRjPaiIZp 3hXLG6kRI/DI9a6+uREX016/HoTFfY/4kGex8owvsEvsRuE0dJcpjAlMMjmA5pZWx1NbF9ZK8PNIB IQ3kWaOo4fLOum1LlNyznj21onY4enpEn0FzvgM54VL5pgzMlBK0Xy501Nv2lx7oK/qQh7HZzcNlD IfzP6qnWhM+6roEkezxCttof0ZX6qeGUIeHTcj5KggYTDFCCVAG9U+tVN0N7X4gSKdxn4FyaWlDup Dr3k0AxHk+iVC39Ure455w==; Date: Mon, 17 Mar 2025 21:41:19 +0200 Message-Id: <86y0x3qwbk.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Mon, 17 Mar 2025 15:17:09 -0400) Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 76969 Cc: dmitry@gutov.dev, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > From: Spencer Baugh > Cc: Dmitry Gutov , 76969@debbugs.gnu.org > Date: Mon, 17 Mar 2025 15:17:09 -0400 > > Eli Zaretskii writes: > >> Date: Sun, 16 Mar 2025 01:29:00 +0200 > >> Cc: 76969@debbugs.gnu.org, sbaugh@janestreet.com > >> From: Dmitry Gutov > >> > >> On 15/03/2025 16:06, Eli Zaretskii wrote: > >> > >> >> My view is that there would be a bunch of threads running concurrently, > >> >> most of them "harmless" - but there would be some that modify buffer > >> >> contents. Having the buffer switched under them could lead to data loss > >> >> in another buffer which happened to be next in the list, with the > >> >> changes quite possibly saved to disk. > >> > > >> > Yes. My point is that terminating each such thread because its > >> > current buffer was killed might be overkill for threads which don't > >> > care about their current-buffer. > >> > >> I wonder if the set of functions which behave safely under such > >> conditions is large enough for this to be the default. > > > > If someone would like to make a survey of use patterns of Lisp > > threads, I think it will be useful in more than one way. > > > >> >> We can't really distinguish between these kinds of threads from the > >> >> outside, so the general model would need to err on the side of safety. > >> > > >> > The side of safety in my book is not to kill the buffer. You > >> > suggested instead to signal the thread, which would terminate it, and > >> > I consider that not erring on the side of safety. > >> > >> Okay... then by default we will not kill the buffer, but allow threads > >> to opt into allowing the buffer to be killed, preceded by a signal? > >> > >> That sounds safe enough. > > > > I actually thought the other way around: kill the buffer and deliver > > the signal, unless a special buffer-local variable is non-nil. > > I agree. I think "kill the buffer and deliver the signal" makes sense > as a default behavior, suppressed when a special buffer-local is > non-nil. > > I think then we wouldn't need a new argument for make-thread, because > threads which care about suppressing kill-buffer can simply set this new > buffer-local variable. The question still stands whether we should deliver the signal to threads which didn't indicate they expect a signal. Don't forget that the target thread could be the main thread. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 17 20:08:11 2025 Received: (at 76969) by debbugs.gnu.org; 18 Mar 2025 00:08:11 +0000 Received: from localhost ([127.0.0.1]:33414 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tuKV8-0002PA-7k for submit@debbugs.gnu.org; Mon, 17 Mar 2025 20:08:10 -0400 Received: from fhigh-b2-smtp.messagingengine.com ([202.12.124.153]:50543) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tuKV5-0002OF-FA for 76969@debbugs.gnu.org; Mon, 17 Mar 2025 20:08:08 -0400 Received: from phl-compute-09.internal (phl-compute-09.phl.internal [10.202.2.49]) by mailfhigh.stl.internal (Postfix) with ESMTP id BB8DC2540258; Mon, 17 Mar 2025 20:08:01 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-09.internal (MEProxy); Mon, 17 Mar 2025 20:08:01 -0400 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=fm3; t=1742256481; x=1742342881; bh=lhhCcdE5NyXCyGrsdWNrYPGsHI46rw8YIGy3pH8GLpM=; b= XUZGiZyVCx+ANP4nkuz/TtGEFr481uQZAMxhKLE9mmOxjvqV2fh7RhszZP1IASXx ZXZ8YyfDv/KUcUJrht0Cohxi6vS1w3GjKkUdsOqgQrgv3Ge3dM1QcIMqoEqlrXPn r/RFHVV7Zib42NA8p1quwdmmsMXx0Snrjg+CaQb/wji0gyEb+edd6qi7YzM5mloK LGa2pmQd+oRzdy4Gvto1tUWChRgoYnu09LAdxbivR093Z0YeO5J0RAX/1avux5bE /UVt9LIZlvfwHhmPd17eM7u7C7RUuavux954OhxhmPcpgJ6K1F30loJ/JvrRWIG6 v3ev9fLjBiLOB0YhMeN7vA== 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=fm1; t=1742256481; x= 1742342881; bh=lhhCcdE5NyXCyGrsdWNrYPGsHI46rw8YIGy3pH8GLpM=; b=u jeoYhHyP3Txnsey+PFDUSs5QukQX+U2q/jIzAJngVAzjM6cTVtuVaTgFxEwrOcvN /qTQf94nJZ7lO05/KyTOt4Vd+Q5b9UbPs5JwoimVY6Xx1dUg86Peq2zfzQLJncaC G8M2vzwHMU+pjAdFsVGRv8Xb2eW6PNHhEt8TD7yE9xG8ohxaz4wK3LFblPEE/TYU Pz/FDk9nL0xtKSm3W2nezSCwC7JSH8Mjt/vrWhQIkbDKDBcxb4rLksE5NB+RQdXW f/75jY9/qTBH6/F+lIRQwEj5ihR3qPF7QH4SZ2Buzj/9XwNyCfKTZUG6rEIfR+RT 1JEoOCADu9CpqqbqbZCaQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddugedtleefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddt vdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovh druggvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieek ueeftddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphht thhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdroh hrghdprhgtphhtthhopeejieelieelseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp thhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 17 Mar 2025 20:07:59 -0400 (EDT) Message-ID: <7cd20943-e7f2-41a6-89d6-ca296e08801e@gutov.dev> Date: Tue, 18 Mar 2025 02:07:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current To: Eli Zaretskii References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86ldt5v78p.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 16/03/2025 08:07, Eli Zaretskii wrote: >> I wonder if the set of functions which behave safely under such >> conditions is large enough for this to be the default. > > If someone would like to make a survey of use patterns of Lisp > threads, I think it will be useful in more than one way. Here's a minor survey: among the packages I have installed there are 2 (!) which use threads, out of 55: lsp-mode and diff-hl, the latter has triggered this discussion. In GNU ELPA, there are also phpinspect, debbugs and phps-mode. >>>> We can't really distinguish between these kinds of threads from the >>>> outside, so the general model would need to err on the side of safety. >>> >>> The side of safety in my book is not to kill the buffer. You >>> suggested instead to signal the thread, which would terminate it, and >>> I consider that not erring on the side of safety. >> >> Okay... then by default we will not kill the buffer, but allow threads >> to opt into allowing the buffer to be killed, preceded by a signal? >> >> That sounds safe enough. > > I actually thought the other way around: kill the buffer and deliver > the signal, unless a special buffer-local variable is non-nil. This sounds like the same description, with the only difference that the said variable is nil by default. If so, sounds good to me. >> But the downside is we retain the current issue, right? As described in >> the original report. > > With your default, yes. OTOH, the original report didn't explain why > not killing the buffer is a problem. Unpredictability, lack of observability, poor debugging. Mentioned all these in the first few messages. > In general, any Lisp program > that calls kill-buffer should be prepared to deal with the fact that > the buffer might not be killed, due to any of the possible reasons > which prevent that already, even if other threads are no involved. Most of which have stayed documented thus far. In any case, as I said in the beginning, we don't have to kill the buffer, but then we should consider other ways of making it clearer why it wasn't killed (to the programmers, to the users). Having the "kill and signal" default would be easier conceptually. >>>> Not sure what thread function you're thinking of in this case. >>> >>> In this analogy, showing buffers is that "thread function". >> >> Okay. So take just a function that is going to display a buffer. If the >> buffer is killed, wouldn't it be better for the > > This sentence seems to be unfinished. Sorry. ...would it be better for the "show buffer" function to be interrupted, rather than have it show a different buffer? This question might be moot already, if we agree that "kill" and "signal" should go together in our scenario (either both happen or neither). >> I was unclear if you think it's better to always kill the buffer, or to >> have that behavior opt-in. > > That's because I don't yet have a firm opinion. And to some extent > that depends on the optional features we will implement: > > . is signal always delivered or only to threads which said they want it? > . do we add a buffer-local dont-ever-kill-my-buffer variable? The difference between these option is really whether the behavior is off or no by default, right? As for whether it's a thread property or a local var, either seems workable to me. >> If the buffer is killed, though, I believe it is better to signal its >> threads. Having the buffer substituted can easily get unnoticed, and >> would be hard to debug. > > And I tend to prefer leaving this to the Lisp program which starts the > thread, via an additional argument to make-thread. I don't think we could make the argument a required one. And as long as it isn't, the question of default stays relevant. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 17 20:21:35 2025 Received: (at 76969) by debbugs.gnu.org; 18 Mar 2025 00:21:35 +0000 Received: from localhost ([127.0.0.1]:33459 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tuKi6-0004ay-9y for submit@debbugs.gnu.org; Mon, 17 Mar 2025 20:21:35 -0400 Received: from fhigh-b2-smtp.messagingengine.com ([202.12.124.153]:55385) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tuKi3-0004a2-Tl for 76969@debbugs.gnu.org; Mon, 17 Mar 2025 20:21:32 -0400 Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfhigh.stl.internal (Postfix) with ESMTP id 7029925401B4; Mon, 17 Mar 2025 20:21:26 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-10.internal (MEProxy); Mon, 17 Mar 2025 20:21:26 -0400 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=fm3; t=1742257286; x=1742343686; bh=BHa0A3oGJotzh/n5Rq6s69l7kvXL8Cs0yZNRhy9sAew=; b= h1uAw9wp/256zPJvBAKxaEX0R4Xap2T8socUFmjws5ZsZpd/TowLa9siNAJqZUlZ gvMrreA5ohaaijfyFBsM9hUYAFr7Gsf6W02GinMA1P3t9cjNqu0dB1Ad8IHNi0hm ZDoQg5tz1bLtJiTgTOllYYpJQPhJtHk0digDtTjtVDpJcMBF9JEOuIDLAWXv4jkg ZrZtlJ4TR0Uy/q15j5c+RFUiu16PE4aQUZOPEfhHTOjn8pZvVcQSEDCxs04cVXVc 0kAExeDHlYB5x8bGgrL07Og8Fh6EV3p3EtQFqsEOl9VNGNlvjDlJtbR+x/MSXSKN FlGd//ZaSA9XuyYQD8HGcw== 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=fm1; t=1742257286; x= 1742343686; bh=BHa0A3oGJotzh/n5Rq6s69l7kvXL8Cs0yZNRhy9sAew=; b=l vh7dHUA1HetUwPKvNC0e9ea2oM9V/GoWtolB5wYs3HE0UchMPGLnqGmifsl8uHzY BMrANNkB9F+m4pTiS/7nLGqkBaY9oOd+KWnYJZyMxRJBFaUIzuHLRxI/zoOkzzzf gps8t7js6sbbTdi1scliMSdu9Uo1X5w0Z7pvJTjGxnBfKoyUbeectaA3k6oOBYSi RprY9pxzyfmj3IzACHIghwvrDHDJ8V1U+dLJTHA6lgiXwFcKo4OhuKGmDLuITEfZ WmEDKymwPXu4JiqISs5CuGnz5SRnZK+HEDQpA5eqnSpwqgqYt3exOFM3rJLlaZ7b 49XfpACK1ikvk/UReV4dg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddugedtleeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddt vdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovh druggvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieek ueeftddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphht thhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdroh hrghdprhgtphhtthhopehssggruhhghhesjhgrnhgvshhtrhgvvghtrdgtohhmpdhrtghp thhtohepjeeileeileesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 17 Mar 2025 20:21:24 -0400 (EDT) Message-ID: <7754f678-6c8e-4045-8c3d-e2b39680f023@gutov.dev> Date: Tue, 18 Mar 2025 02:21:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current To: Eli Zaretskii , Spencer Baugh References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> <86y0x3qwbk.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86y0x3qwbk.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76969 Cc: 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 17/03/2025 21:41, Eli Zaretskii wrote: > Don't forget that > the target thread could be the main thread. Good question what we should do with the main thread in this case - but even if it receives the signal, it should be more a lot more visible to the user than in background threads, helping fix whatever misbehavior that caused it. But we'll probably use the same method that's being discussed to declare a thread an exception, prohibiting its buffer from being killed externally. From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 13 10:02:22 2025 Received: (at 76969) by debbugs.gnu.org; 13 Jul 2025 14:02:22 +0000 Received: from localhost ([127.0.0.1]:53946 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uaxHZ-00065u-8J for submit@debbugs.gnu.org; Sun, 13 Jul 2025 10:02:21 -0400 Received: from fhigh-a6-smtp.messagingengine.com ([103.168.172.157]:47745) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uaxHV-00065b-U6 for 76969@debbugs.gnu.org; Sun, 13 Jul 2025 10:02:18 -0400 Received: from phl-compute-06.internal (phl-compute-06.phl.internal [10.202.2.46]) by mailfhigh.phl.internal (Postfix) with ESMTP id B05641400051; Sun, 13 Jul 2025 10:02:12 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Sun, 13 Jul 2025 10:02:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc: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=1752415332; x=1752501732; bh=+923PsHZqG CsFwhUT/UfygTYQwYH64in3MqS7e4NCok=; b=OGZurROfp7WzBd896DIpzC720/ nalIoBF+EFi1sef2+Rltr5550CxNVkjDKH6lD/Y5FCraj2D/bcsB/yizBwDLRM03 0zaazvBf4m9yfK+avCR/KFwk+Yb126utWy9xx7ks6s3aeQGkWCFMepuM2KCRuabb iycJJOEqO9VGVYirVJXElzzTgcpMgW4kkSonGhz15mYVWSA/yYl9to+1nlxPPZlr 05A5QeBfnQOKltGn63YkUZu8HA5WHOgdKvuCI4vtcCUhoqsnd85AWEjcm9OcqrMG IM7H/wg2Fust+CBEWnG4xyS1KnTU/witA2xc0ftvY7uGSAikNyZ21bDIr2tA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc: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=fm2; t= 1752415332; x=1752501732; bh=+923PsHZqGCsFwhUT/UfygTYQwYH64in3Mq S7e4NCok=; b=Ldkcbdvq07VSbVa5LiF8XEqG0bwdYFibzXy27M3CP+7TVWCnbBe sPCAW1GoNGpsQOfEA8khVhcFOO/LrZFNO7F12b9OYfQNd5PoV8z4JmBwxTAE7yc1 bfrnNWa3zC3yEsZ6vK7pWTizZHfv1SoZHVLGcawXUsGTQf//mgPHKTSwfXVyDjQw 8PWcCm4T1V5KIdpcBWo49O5uMcUHmUVhrvO/bE3zEoSKCnJoAqh/WTep2LHBmeA8 j3q4gH7K1IjM8PukwnWQwjqkfDP+w790/NGkUuVtqb2cXK+turLEZ3JR/SyketkG l7VsdjsktOWinHctSg7MBymSKVzAVM4XUdQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdegledviecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpegtkfffgggfuffhvfevfhgjsehmtderredtvdejnecuhfhrohhmpeffmhhithhrhicu ifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvghrnh eptddvueegvdetledvgeevgfeutdfgteehgfegffektdekgeevieefiedujeeuffffnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrh ihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhu thdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehssggruhhghh esjhgrnhgvshhtrhgvvghtrdgtohhmpdhrtghpthhtohepjeeileeileesuggvsggsuhhg shdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 13 Jul 2025 10:02:10 -0400 (EDT) Content-Type: multipart/mixed; boundary="------------0bWdhEteOYt0Ul0F42w212C7" Message-ID: <54677c11-0274-443c-b2b1-079d73e34d10@gutov.dev> Date: Sun, 13 Jul 2025 17:02:07 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current From: Dmitry Gutov To: Eli Zaretskii , Spencer Baugh References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> <86y0x3qwbk.fsf@gnu.org> <7754f678-6c8e-4045-8c3d-e2b39680f023@gutov.dev> Content-Language: en-US In-Reply-To: <7754f678-6c8e-4045-8c3d-e2b39680f023@gutov.dev> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 76969 Cc: 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) This is a multi-part message in MIME format. --------------0bWdhEteOYt0Ul0F42w212C7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Eli, On 18/03/2025 02:21, Dmitry Gutov wrote: > On 17/03/2025 21:41, Eli Zaretskii wrote: >> Don't forget that >> the target thread could be the main thread. > > Good question what we should do with the main thread in this case - but > even if it receives the signal, it should be more a lot more visible to > the user than in background threads, helping fix whatever misbehavior > that caused it. > > But we'll probably use the same method that's being discussed to declare > a thread an exception, prohibiting its buffer from being killed externally. Here's a patch with implementation: * It's a property of the thread, on by default. * Set to nil for the main thread (currently can be changed from Lisp). * Not a buffer-local variable - and looking more at it, that seems not a good idea, because several threads could have the same buffer current, and some might be okay with this behavior, while others not. * A couple of questions about the finer details of the implementation, see comments in 'thread_all_before_buffer_killed'. * Two tests included. Seems to work well in my testing, and in the diff-hl scenario described in the report: step 5 kills the buffer and sends the signal which I can catch inside condition-case in diff-hl--update-safe. WDYT? --------------0bWdhEteOYt0Ul0F42w212C7 Content-Type: text/x-patch; charset=UTF-8; name="thread-buffer-killable-p.diff" Content-Disposition: attachment; filename="thread-buffer-killable-p.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL3NyYy9idWZmZXIuYyBiL3NyYy9idWZmZXIuYwppbmRleCBhNDY1MTUz Mjc5ZC4uZGQzYjFlZjAxOGQgMTAwNjQ0Ci0tLSBhL3NyYy9idWZmZXIuYworKysgYi9zcmMv YnVmZmVyLmMKQEAgLTIwNTAsNiArMjA1MCw4IEBAIERFRlVOICgia2lsbC1idWZmZXIiLCBG a2lsbF9idWZmZXIsIFNraWxsX2J1ZmZlciwgMCwgMSwgImJLaWxsIGJ1ZmZlcjogIiwKIAly ZXR1cm4gUW5pbDsKICAgICB9CiAKKyAgdGhyZWFkX2FsbF9iZWZvcmVfYnVmZmVyX2tpbGxl ZCAoYnVmZmVyKTsKKwogICAvKiBJZiB0aGUgYnVmZmVyIG5vdyBjdXJyZW50IGlzIHNob3du IGluIHRoZSBtaW5pYnVmZmVyIGFuZCBvdXIgYnVmZmVyCiAgICAgIGlzIHRoZSBzb2xlIG90 aGVyIGJ1ZmZlciBnaXZlIHVwLiAgKi8KICAgWFNFVEJVRkZFUiAodGVtLCBjdXJyZW50X2J1 ZmZlcik7CmRpZmYgLS1naXQgYS9zcmMvdGhyZWFkLmMgYi9zcmMvdGhyZWFkLmMKaW5kZXgg OGZkNzEzZDBjODEuLjg4YzZlOTM0NmFjIDEwMDY0NAotLS0gYS9zcmMvdGhyZWFkLmMKKysr IGIvc3JjL3RocmVhZC5jCkBAIC05MzQsNiArOTM0LDggQEAgREVGVU4gKCJtYWtlLXRocmVh ZCIsIEZtYWtlX3RocmVhZCwgU21ha2VfdGhyZWFkLCAxLCAyLCAwLAogI2VuZGlmCiAgICAg fQogCisgIG5ld190aHJlYWQtPmJ1ZmZlcl9raWxsYWJsZV9wID0gdHJ1ZTsKKwogICAvKiBG SVhNRTogcmFjZSBoZXJlIHdoZXJlIG5ldyB0aHJlYWQgbWlnaHQgbm90IGJlIGZpbGxlZCBp bj8gICovCiAgIExpc3BfT2JqZWN0IHJlc3VsdDsKICAgWFNFVFRIUkVBRCAocmVzdWx0LCBu ZXdfdGhyZWFkKTsKQEAgLTEwMzAsNiArMTAzMiwzOCBAQCBERUZVTiAoInRocmVhZC1saXZl LXAiLCBGdGhyZWFkX2xpdmVfcCwgU3RocmVhZF9saXZlX3AsIDEsIDEsIDAsCiAgIHJldHVy biB0aHJlYWRfbGl2ZV9wICh0c3RhdGUpID8gUXQgOiBRbmlsOwogfQogCitERUZVTiAoInRo cmVhZC1idWZmZXIta2lsbGFibGUtcCIsIEZ0aHJlYWRfYnVmZmVyX2tpbGxhYmxlX3AsIFN0 aHJlYWRfYnVmZmVyX2tpbGxhYmxlX3AsCisgICAgICAgMSwgMSwgMCwKKyAgICAgICBkb2M6 IC8qIFJldHVybiB0IGlmIFRIUkVBRCdzIGJ1ZmZlciBpcyBhbGxvd2VkIHRvIGJlIGtpbGxl ZCBmcm9tCithbm90aGVyIHRocmVhZC4gIFRoaXMgaXMgYSBwcm9wZXJ0eSBvZiB0aGUgdGhy ZWFkLCBub3Qgb2YgYSBidWZmZXIuICAqLykKKyAgKExpc3BfT2JqZWN0IHRocmVhZCkKK3sK KyAgc3RydWN0IHRocmVhZF9zdGF0ZSAqdHN0YXRlOworCisgIENIRUNLX1RIUkVBRCAodGhy ZWFkKTsKKyAgdHN0YXRlID0gWFRIUkVBRCAodGhyZWFkKTsKKworICByZXR1cm4gdHN0YXRl LT5idWZmZXJfa2lsbGFibGVfcCA/IFF0IDogUW5pbDsKK30KKworREVGVU4gKCJ0aHJlYWQt c2V0LWJ1ZmZlci1raWxsYWJsZSIsIEZ0aHJlYWRfc2V0X2J1ZmZlcl9raWxsYWJsZSwgU3Ro cmVhZF9zZXRfYnVmZmVyX2tpbGxhYmxlLAorICAgICAgIDIsIDIsIDAsCisgICAgICAgZG9j OiAvKiBTZXQgd2hldGhlciBUSFJFQUQncyBidWZmZXIgaXMgYWxsb3dlZCB0byBiZSBraWxs ZWQuICAqLykKKyAgKExpc3BfT2JqZWN0IHRocmVhZCwgTGlzcF9PYmplY3QgdmFsdWUpCit7 CisgIHN0cnVjdCB0aHJlYWRfc3RhdGUgKnRzdGF0ZTsKKworICBDSEVDS19USFJFQUQgKHRo cmVhZCk7CisgIHRzdGF0ZSA9IFhUSFJFQUQgKHRocmVhZCk7CisKKyAgaWYgKEVRICh2YWx1 ZSwgUW5pbCkpCisgICAgdHN0YXRlLT5idWZmZXJfa2lsbGFibGVfcCA9IGZhbHNlOworICBl bHNlCisgICAgdHN0YXRlLT5idWZmZXJfa2lsbGFibGVfcCA9IHRydWU7CisKKyAgcmV0dXJu IHZhbHVlOworfQorCiBERUZVTiAoInRocmVhZC0tYmxvY2tlciIsIEZ0aHJlYWRfYmxvY2tl ciwgU3RocmVhZF9ibG9ja2VyLCAxLCAxLCAwLAogICAgICAgIGRvYzogLyogUmV0dXJuIHRo ZSBvYmplY3QgdGhhdCBUSFJFQUQgaXMgYmxvY2tpbmcgb24uCiBJZiBUSFJFQUQgaXMgYmxv Y2tlZCBpbiBgdGhyZWFkLWpvaW4nIG9uIGEgc2Vjb25kIHRocmVhZCwgcmV0dXJuIHRoYXQK QEAgLTExMzksMTMgKzExNzMsNTIgQEAgdGhyZWFkX2NoZWNrX2N1cnJlbnRfYnVmZmVyIChz dHJ1Y3QgYnVmZmVyICpidWZmZXIpCiAgICAgICBpZiAoaXRlciA9PSBjdXJyZW50X3RocmVh ZCkKIAljb250aW51ZTsKIAotICAgICAgaWYgKGl0ZXItPm1fY3VycmVudF9idWZmZXIgPT0g YnVmZmVyKQorICAgICAgaWYgKGl0ZXItPm1fY3VycmVudF9idWZmZXIgPT0gYnVmZmVyICYm ICFpdGVyLT5idWZmZXJfa2lsbGFibGVfcCkKIAlyZXR1cm4gdHJ1ZTsKICAgICB9CiAKICAg cmV0dXJuIGZhbHNlOwogfQogCit2b2lkCit0aHJlYWRfYWxsX2JlZm9yZV9idWZmZXJfa2ls bGVkIChMaXNwX09iamVjdCBjdXJyZW50KQoreworICBzdHJ1Y3QgdGhyZWFkX3N0YXRlICpp dGVyOworICBzdHJ1Y3QgYnVmZmVyICogb3RoZXIgPSBOVUxMOworICBzdHJ1Y3QgYnVmZmVy ICogYiA9IFhCVUZGRVIgKGN1cnJlbnQpOworICBzdHJ1Y3QgdGhyZWFkX3N0YXRlICpjYWxs ZXJfdGhyZWFkID0gY3VycmVudF90aHJlYWQ7CisKKyAgZm9yIChpdGVyID0gYWxsX3RocmVh ZHM7IGl0ZXI7IGl0ZXIgPSBpdGVyLT5uZXh0X3RocmVhZCkKKyAgICB7CisgICAgICBpZiAo aXRlciA9PSBjYWxsZXJfdGhyZWFkKQorCWNvbnRpbnVlOworCisgICAgICAvKiBDb3VsZCBp dGVyLT5idWZmZXJfa2lsbGFibGVfcCBiZSBmYWxzZSBub3c/CisJIEUuZy4gY2hhbmdlZCBi eSBob29rcy4gICovCisgICAgICBpZiAoaXRlci0+bV9jdXJyZW50X2J1ZmZlciA9PSBiKQor CXsKKwkgIExpc3BfT2JqZWN0IHRocmVhZDsKKworCSAgWFNFVFRIUkVBRCAodGhyZWFkLCBp dGVyKTsKKworCSAgaWYgKG90aGVyID09IE5VTEwpCisJICAgIG90aGVyID0gWEJVRkZFUiAo Rm90aGVyX2J1ZmZlciAoY3VycmVudCwgUW5pbCwgUW5pbCkpOworCisJICAvLyBPciB3ZSBj b3VsZCBpbmxpbmUgdGhlIGxhc3QgcGFydCBvZiBpdHMgZGVmaW5pdGlvbi4KKwkgIEZ0aHJl YWRfc2lnbmFsICh0aHJlYWQsIFF0aHJlYWRfYnVmZmVyX2tpbGxlZCwgUW5pbCk7CisKKwkg IC8vIEFyZSB3ZSBva2F5IGp1c3Qgc2V0dGluZyB0aGUgdmFsdWUgaGVyZSwgYW5kIHJlbHlp bmcgb24KKwkgIC8vIHNldF9idWZmZXJfaW50ZXJuYWxfMiBjYWxsIGluIHBvc3RfYWNxdWly ZV9nbG9iYWxfbG9jaz8KKwkgIGl0ZXItPm1fY3VycmVudF9idWZmZXIgPSBvdGhlcjsKKwor CSAgLyogY3VycmVudF90aHJlYWQgPSBpdGVyOyAqLworCSAgLyogc2V0X2J1ZmZlcl9pbnRl cm5hbF8xIChvdGhlcik7ICovCisJfQorICAgIH0KKworICAvKiBjdXJyZW50X3RocmVhZCA9 IGNhbGxlcl90aHJlYWQ7ICovCit9CisKIAwKIAogYm9vbApAQCAtMTE3NCw2ICsxMjQ3LDcg QEAgaW5pdF90aHJlYWRzICh2b2lkKQogI2VuZGlmIC8qIGRlZmluZWQgSEFWRV9BTkRST0lE ICYmICFkZWZpbmVkIEFORFJPSURfU1RVQklGWSAqLwogCiAgIG1haW5fdGhyZWFkLnMudGhy ZWFkX2lkID0gc3lzX3RocmVhZF9zZWxmICgpOworICBtYWluX3RocmVhZC5zLmJ1ZmZlcl9r aWxsYWJsZV9wID0gZmFsc2U7CiAgIGluaXRfYmNfdGhyZWFkICgmbWFpbl90aHJlYWQucy5i Yyk7CiB9CiAKQEAgLTEyMDMsNiArMTI3Nyw4IEBAIHN5bXNfb2ZfdGhyZWFkcyAodm9pZCkK ICAgICAgIGRlZnN1YnIgKCZTY29uZGl0aW9uX211dGV4KTsKICAgICAgIGRlZnN1YnIgKCZT Y29uZGl0aW9uX25hbWUpOwogICAgICAgZGVmc3ViciAoJlN0aHJlYWRfbGFzdF9lcnJvcik7 CisgICAgICBkZWZzdWJyICgmU3RocmVhZF9idWZmZXJfa2lsbGFibGVfcCk7CisgICAgICBk ZWZzdWJyICgmU3RocmVhZF9zZXRfYnVmZmVyX2tpbGxhYmxlKTsKIAogICAgICAgc3RhdGlj cHJvICgmbGFzdF90aHJlYWRfZXJyb3IpOwogICAgICAgbGFzdF90aHJlYWRfZXJyb3IgPSBR bmlsOwpAQCAtMTIxNCw2ICsxMjkwLDEyIEBAIHN5bXNfb2ZfdGhyZWFkcyAodm9pZCkKICAg REVGU1lNIChRbXV0ZXhwLCAibXV0ZXhwIik7CiAgIERFRlNZTSAoUWNvbmRpdGlvbl92YXJp YWJsZV9wLCAiY29uZGl0aW9uLXZhcmlhYmxlLXAiKTsKIAorICBERUZTWU0gKFF0aHJlYWRf YnVmZmVyX2tpbGxlZCwgInRocmVhZC1idWZmZXIta2lsbGVkIik7CisgIEZwdXQgKFF0aHJl YWRfYnVmZmVyX2tpbGxlZCwgUWVycm9yX2NvbmRpdGlvbnMsCisJbGlzdCAoUXRocmVhZF9i dWZmZXJfa2lsbGVkLCBRZXJyb3IpKTsKKyAgRnB1dCAoUXNjYW5fZXJyb3IsIFFlcnJvcl9t ZXNzYWdlLAorCWJ1aWxkX3N0cmluZyAoIlRocmVhZCdzIGN1cnJlbnQgYnVmZmVyIGtpbGxl ZCIpKTsKKwogICBERUZWQVJfTElTUCAoIm1haW4tdGhyZWFkIiwgVm1haW5fdGhyZWFkLAog ICAgIGRvYzogLyogVGhlIG1haW4gdGhyZWFkIG9mIEVtYWNzLiAgKi8pOwogI2lmZGVmIFRI UkVBRFNfRU5BQkxFRApkaWZmIC0tZ2l0IGEvc3JjL3RocmVhZC5oIGIvc3JjL3RocmVhZC5o CmluZGV4IGM0OTY0NTNiMDkwLi5mZDA2ZGNkYjhjNyAxMDA2NDQKLS0tIGEvc3JjL3RocmVh ZC5oCisrKyBiL3NyYy90aHJlYWQuaApAQCAtMTQzLDYgKzE0Myw5IEBAICNkZWZpbmUgbGlz cF9ldmFsX2RlcHRoIChjdXJyZW50X3RocmVhZC0+bV9saXNwX2V2YWxfZGVwdGgpCiAgIHN0 cnVjdCBidWZmZXIgKm1fY3VycmVudF9idWZmZXI7CiAjZGVmaW5lIGN1cnJlbnRfYnVmZmVy IChjdXJyZW50X3RocmVhZC0+bV9jdXJyZW50X2J1ZmZlcikKIAorICAvKiBXaGVuIHRydWUg dGhlIHRocmVhZCdzIGN1cnJlbnQgYnVmZmVyIGNhbiBiZSBraWxsZWQuICAqLworICBib29s IGJ1ZmZlcl9raWxsYWJsZV9wOworCiAgIC8qIEV2ZXJ5IGNhbGwgdG8gcmVfc2VhcmNoLCBl dGMuLCBtdXN0IHBhc3MgJnNlYXJjaF9yZWdzIGFzIHRoZSByZWdzCiAgICAgIGFyZ3VtZW50 IHVubGVzcyB5b3UgY2FuIHNob3cgaXQgaXMgdW5uZWNlc3NhcnkgKGkuZS4sIGlmIHJlX3Nl YXJjaAogICAgICBpcyBjZXJ0YWlubHkgZ29pbmcgdG8gYmUgY2FsbGVkIGFnYWluIGJlZm9y ZSByZWdpb24tYXJvdW5kLW1hdGNoCkBAIC0zMzgsNiArMzQxLDggQEAgWENPTkRWQVIgKExp c3BfT2JqZWN0IGEpCiAKIGJvb2wgdGhyZWFkX2NoZWNrX2N1cnJlbnRfYnVmZmVyIChzdHJ1 Y3QgYnVmZmVyICopOwogCit2b2lkIHRocmVhZF9hbGxfYmVmb3JlX2J1ZmZlcl9raWxsZWQg KExpc3BfT2JqZWN0IGJ1ZmZlcik7CisKIElOTElORV9IRUFERVJfRU5ECiAKICNlbmRpZiAv KiBUSFJFQURfSCAqLwpkaWZmIC0tZ2l0IGEvdGVzdC9zcmMvdGhyZWFkLXRlc3RzLmVsIGIv dGVzdC9zcmMvdGhyZWFkLXRlc3RzLmVsCmluZGV4IDMyMjU0N2MyZTZhLi5lNDk4YWViZDk0 OSAxMDA2NDQKLS0tIGEvdGVzdC9zcmMvdGhyZWFkLXRlc3RzLmVsCisrKyBiL3Rlc3Qvc3Jj L3RocmVhZC10ZXN0cy5lbApAQCAtMzkzLDYgKzM5MywzOSBAQCB0aHJlYWRzLXRlc3QtYnVn MzMwNzMKICAgKGxldCAoKHRoIChtYWtlLXRocmVhZCAnaWdub3JlKSkpCiAgICAgKHNob3Vs ZC1ub3QgKGVxdWFsIHRoIG1haW4tdGhyZWFkKSkpKQogCisoZXJ0LWRlZnRlc3QgdGhyZWFk LWJ1ZmZlci1raWxsYWJsZS1uaWwgKCkKKyAgIlRlc3Qgbm90IGJlaW5nIGFibGUgdG8ga2ls bCBhIGJnIHRocmVhZCdzIGJ1ZmZlci4iCisgIChza2lwLXVubGVzcyAoZmVhdHVyZXAgJ3Ro cmVhZHMpKQorICAobGV0ICgoYnVmIChnZXQtYnVmZmVyLWNyZWF0ZSAiICp0aHJlYWQtYnVm ZmVyLWtpbGxhYmxlLW5pbCoiKSkKKyAgICAgICAgdGhyZWFkKQorICAgICh3aXRoLWN1cnJl bnQtYnVmZmVyIGJ1ZgorICAgICAgKHNldHEgdGhyZWFkCisgICAgICAgICAgICAobWFrZS10 aHJlYWQKKyAgICAgICAgICAgICAobGFtYmRhICgpCisgICAgICAgICAgICAgICAoc2xlZXAt Zm9yIDAuMSkpKSkpCisgICAgKHRocmVhZC1zZXQtYnVmZmVyLWtpbGxhYmxlIHRocmVhZCBu aWwpCisgICAgKGtpbGwtYnVmZmVyIGJ1ZikKKyAgICAoc2hvdWxkIChidWZmZXItbGl2ZS1w IGJ1ZikpCisgICAgOzsgTm8gZXJyb3I6CisgICAgKHRocmVhZC1qb2luIHRocmVhZCkpKQor CisoZXJ0LWRlZnRlc3QgdGhyZWFkLWJ1ZmZlci1raWxsYWJsZS10ICgpCisgICJUZXN0IGtp bGxpbmcgYSBiZyB0aHJlYWQncyBidWZmZXIuIgorICAoc2tpcC11bmxlc3MgKGZlYXR1cmVw ICd0aHJlYWRzKSkKKyAgKGxldCAoKGJ1ZiAoZ2V0LWJ1ZmZlci1jcmVhdGUgIiAqdGhyZWFk LWJ1ZmZlci1raWxsYWJsZS10KiIpKQorICAgICAgICB0aHJlYWQpCisgICAgKHdpdGgtY3Vy cmVudC1idWZmZXIgYnVmCisgICAgICAoc2V0cSB0aHJlYWQKKyAgICAgICAgICAgIChtYWtl LXRocmVhZAorICAgICAgICAgICAgIChsYW1iZGEgKCkKKyAgICAgICAgICAgICAgIChzbGVl cC1mb3IgMC4xKSkpKSkKKyAgICAodGhyZWFkLXNldC1idWZmZXIta2lsbGFibGUgdGhyZWFk IHQpCisgICAgKGtpbGwtYnVmZmVyIGJ1ZikKKyAgICAoc2hvdWxkLW5vdCAoYnVmZmVyLWxp dmUtcCBidWYpKQorICAgIChzaG91bGQtZXJyb3IKKyAgICAgKHRocmVhZC1qb2luIHRocmVh ZCkKKyAgICAgOnR5cGUgJ3RocmVhZC1idWZmZXIta2lsbGVkKSkpCisKIChkZWZ2YXIgdGhy ZWFkcy10ZXN0LS12YXIgJ2dsb2JhbCkKIAogKGVydC1kZWZ0ZXN0IHRocmVhZHMtdGVzdC1i dWc0ODk5MCAoKQo= --------------0bWdhEteOYt0Ul0F42w212C7-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 17 02:26:15 2025 Received: (at 76969) by debbugs.gnu.org; 17 Jul 2025 06:26:15 +0000 Received: from localhost ([127.0.0.1]:52652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ucI4M-0002kM-I7 for submit@debbugs.gnu.org; Thu, 17 Jul 2025 02:26:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53130) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ucI4H-0002jv-88 for 76969@debbugs.gnu.org; Thu, 17 Jul 2025 02:26:12 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ucI4A-0007xx-Uy; Thu, 17 Jul 2025 02:26:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=PrU99RFImCTqsImO1rM3Md7nsjunNK0GKP13P+Tp8wY=; b=myCx2R8xr0Ip FxZF5izGi4eh5UDcNXRz5iXJM6ab7cZyiGJzmzDis1kOlvFRFYSnAdH9hJjk4GzZBpXbBaIGo8s+m VcyiAGspQjbMY86gr+IEw+7ZtYrQog6SxMid8t7vTyURYsMP1H9FTa4O09/xJGJFPB7ty3rUi1J6t nXJ4Rwm1vJCC2YhcjYpEdyAMdteywvM1aidb9lyMoVOMPkhBhPWWGQkZ3jBhg8W63eHIRnqUk3gf4 DwvmhFDwDYkeVUhD1KtY9l8xxWykSxeXwD3N7K6lp2h5g25WVIqt82djrsKBcx3fWD4D0ALrvklzx RmxegaVofctu6WCFL4oErQ==; Date: Thu, 17 Jul 2025 09:25:45 +0300 Message-Id: <86wm87gwpi.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <54677c11-0274-443c-b2b1-079d73e34d10@gutov.dev> (message from Dmitry Gutov on Sun, 13 Jul 2025 17:02:07 +0300) Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> <86y0x3qwbk.fsf@gnu.org> <7754f678-6c8e-4045-8c3d-e2b39680f023@gutov.dev> <54677c11-0274-443c-b2b1-079d73e34d10@gutov.dev> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 13 Jul 2025 17:02:07 +0300 > From: Dmitry Gutov > Cc: 76969@debbugs.gnu.org > > Here's a patch with implementation: > > * It's a property of the thread, on by default. > * Set to nil for the main thread (currently can be changed from Lisp). > * Not a buffer-local variable - and looking more at it, that seems not a > good idea, because several threads could have the same buffer current, > and some might be okay with this behavior, while others not. > * A couple of questions about the finer details of the implementation, > see comments in 'thread_all_before_buffer_killed'. > * Two tests included. > > Seems to work well in my testing, and in the diff-hl scenario described > in the report: step 5 kills the buffer and sends the signal which I can > catch inside condition-case in diff-hl--update-safe. > > WDYT? It's a starting point, thanks. Comments: . I think we should add an optional argument to make-thread, because calling a function to change the buffer_killable_p attribute might be too late (I'm not against having the function as well) . I think we should also allow a thread to say it's fine to kill the current buffer, but not to signal the thread when the buffer is killed (this means the buffer_killable_p should be not just a simple boolean) . we need documentation changes; in particular some of these changes should be called out as incompatible > + for (iter = all_threads; iter; iter = iter->next_thread) > + { > + if (iter == caller_thread) > + continue; > + > + /* Could iter->buffer_killable_p be false now? > + E.g. changed by hooks. */ It is best not to rely on it being true, yes. > + // Or we could inline the last part of its definition. > + Fthread_signal (thread, Qthread_buffer_killed, Qnil); It is better to make that last part be a function, and call it in both places. And note that doing that could potentially switch threads, which we perhaps want to avoid here? > @@ -1174,6 +1247,7 @@ init_threads (void) > #endif /* defined HAVE_ANDROID && !defined ANDROID_STUBIFY */ > > main_thread.s.thread_id = sys_thread_self (); > + main_thread.s.buffer_killable_p = false; Do we allow calling thread-set-buffer-killable on the main thread? > + DEFSYM (Qthread_buffer_killed, "thread-buffer-killed"); > + Fput (Qthread_buffer_killed, Qerror_conditions, > + list (Qthread_buffer_killed, Qerror)); > + Fput (Qscan_error, Qerror_message, ^^^^^^^^^^^ Copy/pasta? From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 17 20:23:58 2025 Received: (at 76969) by debbugs.gnu.org; 18 Jul 2025 00:23:58 +0000 Received: from localhost ([127.0.0.1]:58197 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ucYtJ-0003gY-IM for submit@debbugs.gnu.org; Thu, 17 Jul 2025 20:23:58 -0400 Received: from fout-b8-smtp.messagingengine.com ([202.12.124.151]:43017) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ucYtF-0003g6-9v for 76969@debbugs.gnu.org; Thu, 17 Jul 2025 20:23:54 -0400 Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfout.stl.internal (Postfix) with ESMTP id 6046D1D0011A; Thu, 17 Jul 2025 20:23:47 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Thu, 17 Jul 2025 20:23:47 -0400 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=1752798227; x=1752884627; bh=08svq0oLhUzFANClGoCmrGfvyFFPJVI3PUhwuA7r7ys=; b= XNGmvP1PAouUFOfWqu4iFpV2v4RKCYxkSWWrrUhFC1WsWbpzeNwazkUrW6nxOzzw B3P4QdMGAPqdj69bTfzB83plo/mgpVt4hIbi/xc864mizxOO37c82qCR04TSSUu8 UERlrS+Jw7dmxnRdxRjX5RdRjaNApn8cIAAXb5pGx9FHjMUllJWahCbzJsfzKGod AIpMZpCH+45PkMPZPCi+GIGPkGs32kgBIJPwKY/ZA2o1uZlJNhBp4tIVsLoftrBj wyhNiGnj9twYVPdWm6bwsZhSzMLDhn5igcXsNaNeAJSEeMImsvyQo4wIHb9QG2rb njUJw4A2RCyd0yKlOKtR4Q== 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=fm2; t=1752798227; x= 1752884627; bh=08svq0oLhUzFANClGoCmrGfvyFFPJVI3PUhwuA7r7ys=; b=U tTnQx4u1O7WH/a36+QCTerTQbMZQjAfNIWvDklXwohIe1HdPyySju4R0EBd54ecc 1ZBwnkH4yuFnyZIQ5NJre6XUJjn2DZHIWq7rAVlWIEyTgWhn4VjjNFIuXP5CPxk/ v5NoAXPJNByk9ksVapN/0qUKrFUQxx32p2FJSCqxpX7ZETPxUbxl59K+yceE40Ma ZOFMu8bgioMHi8PnMA78kadWvuO2TAPDjBhHzmwYiv7wzXwy4eIhaf1rGPcfwdEx ln/cSHNUn57i6TIsOojzAXqgTFtSDdYdLP6m5AJ0dMYNwSED8VJR7MDT5hvL42Bg 9TBqdZDLp4Xd4YTTko1yA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdeivddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihhtrhih ucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtthgvrh hnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudejheen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhith hrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohepshgsrghugh hhsehjrghnvghsthhrvggvthdrtghomhdprhgtphhtthhopeejieelieelseguvggssghu ghhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 17 Jul 2025 20:23:45 -0400 (EDT) Message-ID: <9222ba4e-9a3b-4137-ae31-6796c1838d3c@gutov.dev> Date: Fri, 18 Jul 2025 03:23:43 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current To: Eli Zaretskii References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> <86y0x3qwbk.fsf@gnu.org> <7754f678-6c8e-4045-8c3d-e2b39680f023@gutov.dev> <54677c11-0274-443c-b2b1-079d73e34d10@gutov.dev> <86wm87gwpi.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86wm87gwpi.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 17/07/2025 09:25, Eli Zaretskii wrote: >> Date: Sun, 13 Jul 2025 17:02:07 +0300 >> From: Dmitry Gutov >> Cc: 76969@debbugs.gnu.org >> >> Here's a patch with implementation: >> >> * It's a property of the thread, on by default. >> * Set to nil for the main thread (currently can be changed from Lisp). >> * Not a buffer-local variable - and looking more at it, that seems not a >> good idea, because several threads could have the same buffer current, >> and some might be okay with this behavior, while others not. >> * A couple of questions about the finer details of the implementation, >> see comments in 'thread_all_before_buffer_killed'. >> * Two tests included. >> >> Seems to work well in my testing, and in the diff-hl scenario described >> in the report: step 5 kills the buffer and sends the signal which I can >> catch inside condition-case in diff-hl--update-safe. >> >> WDYT? > > It's a starting point, thanks. Comments: > > . I think we should add an optional argument to make-thread, because > calling a function to change the buffer_killable_p attribute might > be too late (I'm not against having the function as well) Do you think there is a chance for the thread to be started between the 'make-thread' and 'thread-set-buffer-killable' calls, even if they go one after another? I considered making it a keyword argument of 'make-thread' but it seems like it might not interest most callers, and so clutter the definition (I couldn't come up with a less awkward name either). Not a strong opinion, though. > . I think we should also allow a thread to say it's fine to kill the > current buffer, but not to signal the thread when the buffer is > killed (this means the buffer_killable_p should be not just a > simple boolean) Sounds good to me. Guess that calls for removing '-p' from the name too. > . we need documentation changes; in particular some of these changes > should be called out as incompatible Sure. >> + for (iter = all_threads; iter; iter = iter->next_thread) >> + { >> + if (iter == caller_thread) >> + continue; >> + >> + /* Could iter->buffer_killable_p be false now? >> + E.g. changed by hooks. */ > > It is best not to rely on it being true, yes. Will update in the next revision. It will probably complicate the calling convention - and create another condition for keeping the buffer. >> + // Or we could inline the last part of its definition. >> + Fthread_signal (thread, Qthread_buffer_killed, Qnil); > > It is better to make that last part be a function, and call it in both > places. I'll probably keep this line as-is for now, and we could revisit this as a small optimization later. > And note that doing that could potentially switch threads, which we > perhaps want to avoid here? Are you referring to the 'tstate->wait_condvar' check? Hmm, I suppose it could hit if the current thread first releases a mutex held by another thread, and then kills its buffer. If that's realistic, a helper function that doesn't do that, might indeed be better. >> @@ -1174,6 +1247,7 @@ init_threads (void) >> #endif /* defined HAVE_ANDROID && !defined ANDROID_STUBIFY */ >> >> main_thread.s.thread_id = sys_thread_self (); >> + main_thread.s.buffer_killable_p = false; > > Do we allow calling thread-set-buffer-killable on the main thread? I didn't want to decide on this myself. Could certainly prohibit it, looking from safety's perspective. Unless somebody thinks of a scenario that would make it useful? >> + DEFSYM (Qthread_buffer_killed, "thread-buffer-killed"); >> + Fput (Qthread_buffer_killed, Qerror_conditions, >> + list (Qthread_buffer_killed, Qerror)); >> + Fput (Qscan_error, Qerror_message, > ^^^^^^^^^^^ > Copy/pasta? Yes, thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 18 02:24:51 2025 Received: (at 76969) by debbugs.gnu.org; 18 Jul 2025 06:24:51 +0000 Received: from localhost ([127.0.0.1]:59834 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uceWZ-0005wu-13 for submit@debbugs.gnu.org; Fri, 18 Jul 2025 02:24:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38120) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uceWT-0005wG-A0 for 76969@debbugs.gnu.org; Fri, 18 Jul 2025 02:24:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uceWM-00022N-Hj; Fri, 18 Jul 2025 02:24:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=8eXi2u4LKAwzfoOm+uxf3m3KNud6Ar1qWy9mXcbdAPM=; b=M60PI76LmQOZ MvDaSYQrCc6vhX/+XyjXyYPFLrmFJSNgQj59o+qJyqZxpp5SELrC39uZeFu/F6lLnFIt+9Wvk+CQT clea+H/78HIlVzjhtNWip5C39dD9EHgshUIWZiLQLdX4FcKsTs9NQS4ZSRYIVpntkOpHVHT5Kxl5D 7CROcBETcatRif3AgqD+J/PqQ3tLu8xdJSCFkluMmfQNWoMt9NIKhokZi4Vfd1B5KJtXKihX1afRS 9K0HUZ/MRwkucASt1ZX+jnyLLbAxzJOYsi3MpMugOfaB9WLO0pZjzA016YzTKPOIyzLRrrkdMxnpU 7R+kEdgP9WzGH0ncrcp2pA==; Date: Fri, 18 Jul 2025 09:24:34 +0300 Message-Id: <86pldyf23h.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <9222ba4e-9a3b-4137-ae31-6796c1838d3c@gutov.dev> (message from Dmitry Gutov on Fri, 18 Jul 2025 03:23:43 +0300) Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> <86y0x3qwbk.fsf@gnu.org> <7754f678-6c8e-4045-8c3d-e2b39680f023@gutov.dev> <54677c11-0274-443c-b2b1-079d73e34d10@gutov.dev> <86wm87gwpi.fsf@gnu.org> <9222ba4e-9a3b-4137-ae31-6796c1838d3c@gutov.dev> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 18 Jul 2025 03:23:43 +0300 > Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org > From: Dmitry Gutov > > > . I think we should add an optional argument to make-thread, because > > calling a function to change the buffer_killable_p attribute might > > be too late (I'm not against having the function as well) > > Do you think there is a chance for the thread to be started between the > 'make-thread' and 'thread-set-buffer-killable' calls, even if they go > one after another? No. But it makes no sense to provide a separate interface if it must always be called immediately after make-thread, or else should be expected to be unreliable. > I considered making it a keyword argument of 'make-thread' but it seems > like it might not interest most callers, and so clutter the definition > (I couldn't come up with a less awkward name either). Not a strong > opinion, though. There's no need for keyword arguments. make-thread has just 2 arguments as of now; adding one more is not going to make the calls awkward, especially if most callers will never pass that additional argument. > > . I think we should also allow a thread to say it's fine to kill the > > current buffer, but not to signal the thread when the buffer is > > killed (this means the buffer_killable_p should be not just a > > simple boolean) > > Sounds good to me. Guess that calls for removing '-p' from the name too. Yes. > >> + // Or we could inline the last part of its definition. > >> + Fthread_signal (thread, Qthread_buffer_killed, Qnil); > > > > It is better to make that last part be a function, and call it in both > > places. > > I'll probably keep this line as-is for now, and we could revisit this as > a small optimization later. > > > And note that doing that could potentially switch threads, which we > > perhaps want to avoid here? > > Are you referring to the 'tstate->wait_condvar' check? The call to flush_stack_call_func if the test succeeds, yes. > Hmm, I suppose it > could hit if the current thread first releases a mutex held by another > thread, and then kills its buffer. > > If that's realistic, a helper function that doesn't do that, might > indeed be better. Yes. > >> + main_thread.s.buffer_killable_p = false; > > > > Do we allow calling thread-set-buffer-killable on the main thread? > > I didn't want to decide on this myself. Could certainly prohibit it, > looking from safety's perspective. > > Unless somebody thinks of a scenario that would make it useful? It's a significant change in behavior, so I doubt that. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 21 19:50:57 2025 Received: (at 76969) by debbugs.gnu.org; 21 Jul 2025 23:50:57 +0000 Received: from localhost ([127.0.0.1]:60301 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ue0HY-00077u-J9 for submit@debbugs.gnu.org; Mon, 21 Jul 2025 19:50:57 -0400 Received: from fhigh-b8-smtp.messagingengine.com ([202.12.124.159]:41599) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ue0HV-00077V-Pz for 76969@debbugs.gnu.org; Mon, 21 Jul 2025 19:50:54 -0400 Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfhigh.stl.internal (Postfix) with ESMTP id 510FB7A0128; Mon, 21 Jul 2025 19:50:48 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-07.internal (MEProxy); Mon, 21 Jul 2025 19:50:48 -0400 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=1753141848; x=1753228248; bh=F3sw90ghO6jfu4nNm4fdOF+g2t3s/jKtUs4c/M2pobw=; b= NpbPUKmscDaxYhIXtx9jxHrmgoKRA7VzxLPvVowosorpV1JsZ8Ud9dmPSBI5YEpE Ivfezv/fnz8EaTmEMojqmVP8yQ8bheHQHt3EXqnTqC3bfkvF9sXllwRVKDc+TU8n smBn8zPoiZ6eRKkJiOoJzgWk/I7KVVdxsRWQc+naGoLp+5yDr0PXCJ3EZhF1xQpm GzIDk7CMO5w35231allpBibIzuagMOZqh+P4HRgiiRkdYm0AV7M8de9qImw+jv72 oG0/jC58i0WOSCBmDftcyXFhvFuYfw+HNn762yMysCtMg87PGb/ryv6lBeAp87MX MGGXg9CS4t3cMJJoko/ICg== 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=fm2; t=1753141848; x= 1753228248; bh=F3sw90ghO6jfu4nNm4fdOF+g2t3s/jKtUs4c/M2pobw=; b=P bsBkeSENKecBv77eDCOTJOAtSCoBmC1YIis4jQJI476o0nh5P3lRV6VAX864BEV2 QyVIUXekSfGeNKJnkLIbJCiJRs1gG+l/5P+T+v1ZKLj6RkJQ9KLxKKalYjArfeZE 4a5uGJwau95YsRPy1vSHtGB/xMRh6vQCL0ciF13a8Tdx6ZioPPSKrKHp1ixlQ88R HqRy+ggTT3qO470jnCAcRlcho5F1iW4fXobxoc74W8TYCvw/YczaFLJKYarnQjXj fSk27IxLWGKmujqFVrs21r6OWAZzZpNNwJUyVo0Jp25CnjMxTvxciGMU6MznfXuR CJcohzjhW9yQrNRYdEzFg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdejfeeggecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihhtrhih ucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtthgvrh hnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudejheen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhith hrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohepshgsrghugh hhsehjrghnvghsthhrvggvthdrtghomhdprhgtphhtthhopeejieelieelseguvggssghu ghhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 21 Jul 2025 19:50:46 -0400 (EDT) Message-ID: <4a54a7ec-1d38-4d8b-be7f-e7e0ea55d94f@gutov.dev> Date: Tue, 22 Jul 2025 02:50:44 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current To: Eli Zaretskii References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> <86y0x3qwbk.fsf@gnu.org> <7754f678-6c8e-4045-8c3d-e2b39680f023@gutov.dev> <54677c11-0274-443c-b2b1-079d73e34d10@gutov.dev> <86wm87gwpi.fsf@gnu.org> <9222ba4e-9a3b-4137-ae31-6796c1838d3c@gutov.dev> <86pldyf23h.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86pldyf23h.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 18/07/2025 09:24, Eli Zaretskii wrote: >> Date: Fri, 18 Jul 2025 03:23:43 +0300 >> Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org >> From: Dmitry Gutov >> >>> . I think we should add an optional argument to make-thread, because >>> calling a function to change the buffer_killable_p attribute might >>> be too late (I'm not against having the function as well) >> >> Do you think there is a chance for the thread to be started between the >> 'make-thread' and 'thread-set-buffer-killable' calls, even if they go >> one after another? > > No. But it makes no sense to provide a separate interface if it must > always be called immediately after make-thread, or else should be > expected to be unreliable. > >> I considered making it a keyword argument of 'make-thread' but it seems >> like it might not interest most callers, and so clutter the definition >> (I couldn't come up with a less awkward name either). Not a strong >> opinion, though. > > There's no need for keyword arguments. make-thread has just 2 > arguments as of now; adding one more is not going to make the calls > awkward, especially if most callers will never pass that additional > argument. All right. So if we make it an optional argument of 'make-thread', and the default is for thread's buffer to be killable, that might call for a name change (flipping the meaning). Should it be (make-thread FUNCTION &optional NAME BUFFER-PROTECTED) ? With default nil and other possible values 't' and 'kill-silently'. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 22 08:54:38 2025 Received: (at 76969) by debbugs.gnu.org; 22 Jul 2025 12:54:38 +0000 Received: from localhost ([127.0.0.1]:36223 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ueCVy-00062e-BD for submit@debbugs.gnu.org; Tue, 22 Jul 2025 08:54:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43210) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ueCVs-000622-Rm for 76969@debbugs.gnu.org; Tue, 22 Jul 2025 08:54:35 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ueCVm-0001kJ-Kw; Tue, 22 Jul 2025 08:54:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Jw3YTaHdzNqPfwQdBPXTkWQDNmZUhYIRgGtMYGj6MIQ=; b=LBH5+PhxTofs dGKqgyrlzW5K3u4CXfCCnfy13PvF+qXoE495YQ35aSd9rxKR2YNh1MeTEO+2U3QYZKOTC1HkcvCW3 sAdhsZb5bt9XV8yW5+TCAO0ieJXbYOrc0rfeR9rzDh1GDGOmK6QVqz045caKw8vtkMQ+gCsb/wJFF P7JbAtVBrSQjsKN0mayn5p8JjEQwTjMKz6dv5ot888jTpb6w9H07oo5ArtY5cnxxO8mTXc9vz5Jnk lGr9A/ZGVCqMhnGOjRTXHMB73g3bwK1vAlCtLqqX4jCU812mzDzj1EWrzBlxNtkSE0inzPZAB7Ah7 rql8gwo/wWcrvFPM0iZhIw==; Date: Tue, 22 Jul 2025 15:54:23 +0300 Message-Id: <86ikjk9yio.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <4a54a7ec-1d38-4d8b-be7f-e7e0ea55d94f@gutov.dev> (message from Dmitry Gutov on Tue, 22 Jul 2025 02:50:44 +0300) Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> <86y0x3qwbk.fsf@gnu.org> <7754f678-6c8e-4045-8c3d-e2b39680f023@gutov.dev> <54677c11-0274-443c-b2b1-079d73e34d10@gutov.dev> <86wm87gwpi.fsf@gnu.org> <9222ba4e-9a3b-4137-ae31-6796c1838d3c@gutov.dev> <86pldyf23h.fsf@gnu.org> <4a54a7ec-1d38-4d8b-be7f-e7e0ea55d94f@gutov.dev> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 22 Jul 2025 02:50:44 +0300 > Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org > From: Dmitry Gutov > > On 18/07/2025 09:24, Eli Zaretskii wrote: > >> Date: Fri, 18 Jul 2025 03:23:43 +0300 > >> Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org > >> From: Dmitry Gutov > >> > >>> . I think we should add an optional argument to make-thread, because > >>> calling a function to change the buffer_killable_p attribute might > >>> be too late (I'm not against having the function as well) > >> > >> Do you think there is a chance for the thread to be started between the > >> 'make-thread' and 'thread-set-buffer-killable' calls, even if they go > >> one after another? > > > > No. But it makes no sense to provide a separate interface if it must > > always be called immediately after make-thread, or else should be > > expected to be unreliable. > > > >> I considered making it a keyword argument of 'make-thread' but it seems > >> like it might not interest most callers, and so clutter the definition > >> (I couldn't come up with a less awkward name either). Not a strong > >> opinion, though. > > > > There's no need for keyword arguments. make-thread has just 2 > > arguments as of now; adding one more is not going to make the calls > > awkward, especially if most callers will never pass that additional > > argument. > > All right. > > So if we make it an optional argument of 'make-thread', and the default > is for thread's buffer to be killable, that might call for a name change > (flipping the meaning). > > Should it be > > (make-thread FUNCTION &optional NAME BUFFER-PROTECTED) > > ? I'd prefer to call that argument BUFFER-DISPOSITION. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 22 21:39:47 2025 Received: (at 76969) by debbugs.gnu.org; 23 Jul 2025 01:39:47 +0000 Received: from localhost ([127.0.0.1]:46667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ueOSQ-0003gJ-Se for submit@debbugs.gnu.org; Tue, 22 Jul 2025 21:39:47 -0400 Received: from fout-a1-smtp.messagingengine.com ([103.168.172.144]:48781) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ueOSN-0003fk-ET for 76969@debbugs.gnu.org; Tue, 22 Jul 2025 21:39:44 -0400 Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfout.phl.internal (Postfix) with ESMTP id 37A43EC0264; Tue, 22 Jul 2025 21:39:38 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-10.internal (MEProxy); Tue, 22 Jul 2025 21:39:38 -0400 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=1753234778; x=1753321178; bh=s0TuNlAAw0jixTr+47pUTD6RDksQ1lIKSw9Hq1Tr8EI=; b= LOhIOYUAF7RwDw+Sof7sLBLVWhhffdAk1pCnMamAF+ogauEmAEbXTy7IokFWI4Hq soyC//ETiQJYoMX+aCzcNNerTvPw8Qs5//Dxk4NAVmNcaNZmOrhfp5UI1ckm/0g7 48jKeWERzo/mDDCXNVyVSIeJIr4dBORTw6RCL8pkf/YvOha6/u+tB+TtZ+wW0c+o USXXbg9qIm70JqFm02vZj94FYqQjZXZpnVTWgBdAZmWWJLce1abg0jH9Bl4X+6iG a7wFDA9y7k+h4SY8jqpDqt1CKnORrQPTHw5RIb+VlaPIBJD3dZKY3SeIcvI8u1yo dCLR84gdUZiqxKhzCK+xPw== 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=fm2; t=1753234778; x= 1753321178; bh=s0TuNlAAw0jixTr+47pUTD6RDksQ1lIKSw9Hq1Tr8EI=; b=i 4TwCN9NScS9nn16JW/R4kNfkSWfyN9GhpVu2fklN7Mf/JJZeCVLfu5nQEqSLM8U5 FQR+36BVQVcsTzJeRA5PI12grV1ALvkJpMRV2QXLCNBoCUIa0f9BfOgaQLf3Zoge bBk52sKG6cP4enTdAcd1R2YNcj6vnMJlPcAs9oRMyBtfYXT4JbYMZqICPUiq3IBs TWCi8xqreXE73/qcn+kyvE2opbsViqGhQW9Lvoy6XBaDZhpm0D7+MllaBNNG1vTF XkQELqY/4j36LWAwIWlj4sfN28qOHCWfsWqxTWxeT7y+rrkEu+6N2GAp6N37vkSi /usz9tPLv4lF+iSlyEqig== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdejieegkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihhtrhih ucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtthgvrh hnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudejheen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhith hrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohepshgsrghugh hhsehjrghnvghsthhrvggvthdrtghomhdprhgtphhtthhopeejieelieelseguvggssghu ghhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 22 Jul 2025 21:39:36 -0400 (EDT) Message-ID: <485bb371-7452-4ff4-9727-2397f7cc6993@gutov.dev> Date: Wed, 23 Jul 2025 04:39:33 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current To: Eli Zaretskii References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> <86y0x3qwbk.fsf@gnu.org> <7754f678-6c8e-4045-8c3d-e2b39680f023@gutov.dev> <54677c11-0274-443c-b2b1-079d73e34d10@gutov.dev> <86wm87gwpi.fsf@gnu.org> <9222ba4e-9a3b-4137-ae31-6796c1838d3c@gutov.dev> <86pldyf23h.fsf@gnu.org> <4a54a7ec-1d38-4d8b-be7f-e7e0ea55d94f@gutov.dev> <86ikjk9yio.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86ikjk9yio.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 22/07/2025 15:54, Eli Zaretskii wrote: >> So if we make it an optional argument of 'make-thread', and the default >> is for thread's buffer to be killable, that might call for a name change >> (flipping the meaning). >> >> Should it be >> >> (make-thread FUNCTION &optional NAME BUFFER-PROTECTED) >> >> ? > I'd prefer to call that argument BUFFER-DISPOSITION. I had to google it just now. A term from POSIX signals? Makes certain sense. Seems like the default value would have to be nil, though, if it's passed as an optional argument to a function. Are we okay with nil meaning "thread's buffer is killed and sent a signal", t meaning "thread's buffer is never killed" and 'silently' meaning "thread's buffer is killed without a signal"? From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 23 07:37:07 2025 Received: (at 76969) by debbugs.gnu.org; 23 Jul 2025 11:37:07 +0000 Received: from localhost ([127.0.0.1]:48981 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ueXmU-0007zI-D2 for submit@debbugs.gnu.org; Wed, 23 Jul 2025 07:37:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47774) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ueXmQ-0007yC-DP for 76969@debbugs.gnu.org; Wed, 23 Jul 2025 07:37:04 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ueXmJ-0002fu-Q0; Wed, 23 Jul 2025 07:36:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=LAjrTX1fgT6Z6XR8Mf8H5600aKM1HVyTdxQ4Te/hmL4=; b=IqurWDGTGyG/ Pk+/vRAEQr96Gp/A1yeCc48Fz5ODj7tqg4Nw63FOiCRoA8nsRkuRlYjnLbQ+vq1ZfonIQrsIW7Bw+ +X883m83+bzXPCg3yprajfo6kinlx0PUsczelf/g5on0xi8x+vSnSwda1EcALE8WwZfrsJjuutbP+ Ti/5jTI4aULAfXdDZBG765W6inqU6baKTHSj7AFoiCkpTp5Zzo1Xhb3obczrBAR6cCLsVvRAaMXjK ET/P6URtiS58bGc0uPWdwwYorgzO2E7WgqKaDZI0XN3zI5dsyFoA/yNLunpog40ycNm6FLQq1z2le y328Xf+6NXTJVBIwu70YPg==; Date: Wed, 23 Jul 2025 14:36:52 +0300 Message-Id: <86o6tb6svf.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <485bb371-7452-4ff4-9727-2397f7cc6993@gutov.dev> (message from Dmitry Gutov on Wed, 23 Jul 2025 04:39:33 +0300) Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> <86y0x3qwbk.fsf@gnu.org> <7754f678-6c8e-4045-8c3d-e2b39680f023@gutov.dev> <54677c11-0274-443c-b2b1-079d73e34d10@gutov.dev> <86wm87gwpi.fsf@gnu.org> <9222ba4e-9a3b-4137-ae31-6796c1838d3c@gutov.dev> <86pldyf23h.fsf@gnu.org> <4a54a7ec-1d38-4d8b-be7f-e7e0ea55d94f@gutov.dev> <86ikjk9yio.fsf@gnu.org> <485bb371-7452-4ff4-9727-2397f7cc6993@gutov.dev> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 23 Jul 2025 04:39:33 +0300 > Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org > From: Dmitry Gutov > > On 22/07/2025 15:54, Eli Zaretskii wrote: > >> So if we make it an optional argument of 'make-thread', and the default > >> is for thread's buffer to be killable, that might call for a name change > >> (flipping the meaning). > >> > >> Should it be > >> > >> (make-thread FUNCTION &optional NAME BUFFER-PROTECTED) > >> > >> ? > > I'd prefer to call that argument BUFFER-DISPOSITION. > > I had to google it just now. A term from POSIX signals? Or from email messages. > Makes certain sense. > > Seems like the default value would have to be nil, though, if it's > passed as an optional argument to a function. Yes. But given that this isn't a simple boolean, what it means when disposition = nil is open to interpretation, and the doc string should say clearly what that means. > Are we okay with nil meaning "thread's buffer is killed and sent a > signal", t meaning "thread's buffer is never killed" and 'silently' > meaning "thread's buffer is killed without a signal"? Maybe. I'm not sure there's a definite agreement about the default. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 23 16:41:51 2025 Received: (at 76969) by debbugs.gnu.org; 23 Jul 2025 20:41:51 +0000 Received: from localhost ([127.0.0.1]:52216 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uegHe-000635-Li for submit@debbugs.gnu.org; Wed, 23 Jul 2025 16:41:50 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:34955) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uegHb-00062h-PJ for 76969@debbugs.gnu.org; Wed, 23 Jul 2025 16:41:49 -0400 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current In-Reply-To: <86o6tb6svf.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 23 Jul 2025 14:36:52 +0300") References: <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> <86y0x3qwbk.fsf@gnu.org> <7754f678-6c8e-4045-8c3d-e2b39680f023@gutov.dev> <54677c11-0274-443c-b2b1-079d73e34d10@gutov.dev> <86wm87gwpi.fsf@gnu.org> <9222ba4e-9a3b-4137-ae31-6796c1838d3c@gutov.dev> <86pldyf23h.fsf@gnu.org> <4a54a7ec-1d38-4d8b-be7f-e7e0ea55d94f@gutov.dev> <86ikjk9yio.fsf@gnu.org> <485bb371-7452-4ff4-9727-2397f7cc6993@gutov.dev> <86o6tb6svf.fsf@gnu.org> Date: Wed, 23 Jul 2025 16:41:42 -0400 Message-ID: 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=1753303302; bh=dE58kmiq/fcfVKdybXI8fS1mTfX51Cnr/evKL3nlk8E=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=JmvEnlt2MoDKt7xi5l8XBZkZ+9X6YXGWa3RHl1WofsYq20kTgrSfLRLbnHUOevV0n HpcdmmGbdqVEjEvC6XvZIxGWyuWtFJyICKige/ZxZrrerDVb/iuZLa11wF4NkUQKd+ +6g5T2hvzOTep8gsrIIANAj67KGLU5zAVLOquTf4BxavRmbaDHfEG/EfUVb4SvzY78 Lo7IlQP2DKCJMUgFE/VmUUfYdK3NwP0z7POFGs7qB4FPY79eRh//9LzsAKnEvzbcJp gjPJd9LMUAixjZOxQ9gy0WzudWY0V4kMM3aQfFtI3tAdcCVbZ+9HcMuF6wl4YCXHwk aGVBUos4UGYlw== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76969 Cc: Dmitry Gutov , 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> Date: Wed, 23 Jul 2025 04:39:33 +0300 >> Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org >> From: Dmitry Gutov >> >> On 22/07/2025 15:54, Eli Zaretskii wrote: >> >> So if we make it an optional argument of 'make-thread', and the default >> >> is for thread's buffer to be killable, that might call for a name change >> >> (flipping the meaning). >> >> >> >> Should it be >> >> >> >> (make-thread FUNCTION &optional NAME BUFFER-PROTECTED) >> >> >> >> ? >> > I'd prefer to call that argument BUFFER-DISPOSITION. >> >> I had to google it just now. A term from POSIX signals? > > Or from email messages. > >> Makes certain sense. >> >> Seems like the default value would have to be nil, though, if it's >> passed as an optional argument to a function. > > Yes. But given that this isn't a simple boolean, what it means when > disposition = nil is open to interpretation, and the doc string should > say clearly what that means. > >> Are we okay with nil meaning "thread's buffer is killed and sent a >> signal", t meaning "thread's buffer is never killed" and 'silently' >> meaning "thread's buffer is killed without a signal"? > > Maybe. I'm not sure there's a definite agreement about the default. Just as one vote, I'm in favor of "thread's buffer is killed and sent a signal" being the default behavior. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 23 21:32:23 2025 Received: (at 76969) by debbugs.gnu.org; 24 Jul 2025 01:32:23 +0000 Received: from localhost ([127.0.0.1]:53127 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uekoo-0000MH-0U for submit@debbugs.gnu.org; Wed, 23 Jul 2025 21:32:22 -0400 Received: from fhigh-b2-smtp.messagingengine.com ([202.12.124.153]:49227) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uekog-0000Lq-Sa for 76969@debbugs.gnu.org; Wed, 23 Jul 2025 21:32:18 -0400 Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfhigh.stl.internal (Postfix) with ESMTP id 485FB7A0CCF; Wed, 23 Jul 2025 21:32:09 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Wed, 23 Jul 2025 21:32:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc: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=1753320729; x=1753407129; bh=IK1aEgmaiy YNyLJCnjZvVDYlF+5YxfyM47MIyy6WCjI=; b=Lx+99odOzdyd25lYwwCkN8r8Bm JuYwqjLhxj5boQV+NM3qFhnmslgabsM6d66wzgi16ZBbmwrbPqGcls9j7KbfXG9M gKjZKcomMIlu5Z6BOhcfWpLhXze4dlZoshSamOEX1IaDIXS1f1cl8JGom4aQqn5L 53uAORJqxS1GqHc4enwalu2WbgsBO/R3OqagQivVQLsOxWXVZ4vOTQvum8VKaZRP MiPiuVsMWCjvFv8Z5EpMnL9tIh4XvIbE4SgvG9KV0aBvQpOxRuq03tXqI6PIjQaV +EP5+7wfoTwkE+WwSdgCBNmF8jnie6LyY8ROOm5JENa2Zb0GZK05XAPv9RWg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc: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=fm2; t= 1753320729; x=1753407129; bh=IK1aEgmaiyYNyLJCnjZvVDYlF+5YxfyM47M Iyy6WCjI=; b=Cypk0Jtu3eCu2/Kbp+faFkK3fExma5JGfOtjwjdA+syHdzNUAQF OVfc0sKt81hO+tQItx6e8n2/frz56swwuGNrcQQsqy6An8V47SA3gdGWgqcK7m6G dZuhrLV/t7tRn8/EyQ7km7XKqUuPFhNDsG+svu090EHzo/6i/CIXAzN/nCZQa395 2uZRau/67ZItPbxruC/XS7MCfYXk+O2yOkSbFr2IS38sMk4Fb6+afnLVH3NJLBA7 mPm/FSZfX7jI+ccFdDza81hAjG4XYuQ6GsZkaxm7JOBlm5Eh+12foXeH9Zybd+Hz sGPBlexWCIfTKD/HA8FI2DfqyZJva1TOG9A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdejleefgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpegtkfffgggfuffvvehfhfgjsehmtderredtvdejnecuhfhrohhmpeffmhhithhrhicu ifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvghrnh epheelfedukeduudevkeeilefgieffvdekhfekleejueejgeeukeevffekjeejveehnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrh ihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhu thdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehssggruhhghh esjhgrnhgvshhtrhgvvghtrdgtohhmpdhrtghpthhtohepjeeileeileesuggvsggsuhhg shdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 23 Jul 2025 21:32:07 -0400 (EDT) Content-Type: multipart/mixed; boundary="------------GdOYfT9QjY4pXTdBUIgPTGhb" Message-ID: Date: Thu, 24 Jul 2025 04:32:05 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current To: Eli Zaretskii References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> <86y0x3qwbk.fsf@gnu.org> <7754f678-6c8e-4045-8c3d-e2b39680f023@gutov.dev> <54677c11-0274-443c-b2b1-079d73e34d10@gutov.dev> <86wm87gwpi.fsf@gnu.org> <9222ba4e-9a3b-4137-ae31-6796c1838d3c@gutov.dev> <86pldyf23h.fsf@gnu.org> <4a54a7ec-1d38-4d8b-be7f-e7e0ea55d94f@gutov.dev> <86ikjk9yio.fsf@gnu.org> <485bb371-7452-4ff4-9727-2397f7cc6993@gutov.dev> <86o6tb6svf.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86o6tb6svf.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) This is a multi-part message in MIME format. --------------GdOYfT9QjY4pXTdBUIgPTGhb Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 23/07/2025 14:36, Eli Zaretskii wrote: >> Date: Wed, 23 Jul 2025 04:39:33 +0300 >> Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org >> From: Dmitry Gutov >> >> On 22/07/2025 15:54, Eli Zaretskii wrote: >>>> So if we make it an optional argument of 'make-thread', and the default >>>> is for thread's buffer to be killable, that might call for a name change >>>> (flipping the meaning). >>>> >>>> Should it be >>>> >>>> (make-thread FUNCTION &optional NAME BUFFER-PROTECTED) >>>> >>>> ? >>> I'd prefer to call that argument BUFFER-DISPOSITION. >> >> I had to google it just now. A term from POSIX signals? > > Or from email messages. In the context of emails the meaning seems different (more like how the content is displayed). Although it just occurred to me that the word is derived from the root "dispose". >> Makes certain sense. >> >> Seems like the default value would have to be nil, though, if it's >> passed as an optional argument to a function. > > Yes. But given that this isn't a simple boolean, what it means when > disposition = nil is open to interpretation, and the doc string should > say clearly what that means. Sure. >> Are we okay with nil meaning "thread's buffer is killed and sent a >> signal", t meaning "thread's buffer is never killed" and 'silently' >> meaning "thread's buffer is killed without a signal"? > > Maybe. I'm not sure there's a definite agreement about the default. Here's a patch that implements the new default. I think there are no places in the manual where exceptions to killing a buffer are exhaustively described, so I just updated the description for 'make-thread'. LMK if something was missed. --------------GdOYfT9QjY4pXTdBUIgPTGhb Content-Type: text/x-patch; charset=UTF-8; name="thread-buffer-disposition.diff" Content-Disposition: attachment; filename="thread-buffer-disposition.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2RvYy9saXNwcmVmL3RocmVhZHMudGV4aSBiL2RvYy9saXNwcmVmL3Ro cmVhZHMudGV4aQppbmRleCAzZDllYmYwODA3My4uMzE3MTNiY2FiMTAgMTAwNjQ0Ci0tLSBh L2RvYy9saXNwcmVmL3RocmVhZHMudGV4aQorKysgYi9kb2MvbGlzcHJlZi90aHJlYWRzLnRl eGkKQEAgLTU1LDcgKzU1LDcgQEAgQmFzaWMgVGhyZWFkIEZ1bmN0aW9ucwogZGlyZWN0bHks IGJ1dCB0aGUgY3VycmVudCB0aHJlYWQgY2FuIGJlIGV4aXRlZCBpbXBsaWNpdGx5LCBhbmQg b3RoZXIKIHRocmVhZHMgY2FuIGJlIHNpZ25hbGVkLgogCi1AZGVmdW4gbWFrZS10aHJlYWQg ZnVuY3Rpb24gJm9wdGlvbmFsIG5hbWUKK0BkZWZ1biBtYWtlLXRocmVhZCBmdW5jdGlvbiAm b3B0aW9uYWwgbmFtZSBidWZmZXItZGlzcG9zaXRpb24KIENyZWF0ZSBhIG5ldyB0aHJlYWQg b2YgZXhlY3V0aW9uIHdoaWNoIGludm9rZXMgQHZhcntmdW5jdGlvbn0uICBXaGVuCiBAdmFy e2Z1bmN0aW9ufSByZXR1cm5zLCB0aGUgdGhyZWFkIGV4aXRzLgogCkBAIC02Niw2ICs2Niwx MyBAQCBCYXNpYyBUaHJlYWQgRnVuY3Rpb25zCiB1c2VkIGZvciBkZWJ1Z2dpbmcgYW5kIGlu Zm9ybWF0aW9uYWwgcHVycG9zZXMgb25seTsgaXQgaGFzIG5vIG1lYW5pbmcKIHRvIEVtYWNz LiAgSWYgQHZhcntuYW1lfSBpcyBwcm92aWRlZCwgaXQgbXVzdCBiZSBhIHN0cmluZy4KIAor QHZhcntidWZmZXItZGlzcG9zaXRpb259IGluZGljYXRlcyB3aGF0IGhhcHBlbnMgaWYgdGhl IHRocmVhZCdzIGN1cnJlbnQKK2J1ZmZlciBpcyBhYm91dCB0byBiZSBraWxsZWQuICBJZiB0 aGUgdmFsdWUgaXMgQGNvZGV7dH0sIGl0J3Mgbm90CithbGxvd2VkLiAgQW55IG90aGVyIHZh bHVlLCBpbmNsdWRpbmcgbmlsICh3aGljaCBpcyB0aGUgZGVmYXVsdCksIG1lYW5zCit0aGF0 IHRoZSBidWZmZXIgaXMga2lsbGVkIGFuZCB0aGUgdGhyZWFkIGlzIGFzc2lnbmVkIGFub3Ro ZXIgY3VycmVudAorYnVmZmVyLCBhbmQgaXQncyBzaWduYWxlZCB0aGUgZXJyb3IgQGNvZGV7 dGhyZWFkLWJ1ZmZlci1raWxsZWR9LiAgQnV0IGlmCit0aGUgdmFsdWUgaXMgdGhlIHN5bWJv bCBAY29kZXtzaWxlbnRseX0sIHRoZSBlcnJvciBpcyBub3Qgc2lnbmFsZWQuCisKIFRoaXMg ZnVuY3Rpb24gcmV0dXJucyB0aGUgbmV3IHRocmVhZC4KIEBlbmQgZGVmdW4KIApkaWZmIC0t Z2l0IGEvc3JjL2J1ZmZlci5jIGIvc3JjL2J1ZmZlci5jCmluZGV4IGE0NjUxNTMyNzlkLi5l NDRiNmRhZjU4NyAxMDA2NDQKLS0tIGEvc3JjL2J1ZmZlci5jCisrKyBiL3NyYy9idWZmZXIu YwpAQCAtMjA1MCw2ICsyMDUwLDEzIEBAIERFRlVOICgia2lsbC1idWZmZXIiLCBGa2lsbF9i dWZmZXIsIFNraWxsX2J1ZmZlciwgMCwgMSwgImJLaWxsIGJ1ZmZlcjogIiwKIAlyZXR1cm4g UW5pbDsKICAgICB9CiAKKyAgLyogQ2hlY2sgYWxsIHRocmVhZHMgYWdhaW4sIGluIGNhc2Ug YSBob29rIGNoYW5nZWQgc29tZXRoaW5nLiAgKi8KKyAgaWYgKHRocmVhZF9jaGVja19jdXJy ZW50X2J1ZmZlciAoYikpCisgICAgcmV0dXJuIFFuaWw7CisKKyAgLyogQ2xlYW4gdXAgcmVm ZXJlbmNlcyB0byB0aGUgYnVmZmVyIGluIHRocmVhZHMuICAqLworICB0aHJlYWRfYWxsX2Jl Zm9yZV9idWZmZXJfa2lsbGVkIChidWZmZXIpOworCiAgIC8qIElmIHRoZSBidWZmZXIgbm93 IGN1cnJlbnQgaXMgc2hvd24gaW4gdGhlIG1pbmlidWZmZXIgYW5kIG91ciBidWZmZXIKICAg ICAgaXMgdGhlIHNvbGUgb3RoZXIgYnVmZmVyIGdpdmUgdXAuICAqLwogICBYU0VUQlVGRkVS ICh0ZW0sIGN1cnJlbnRfYnVmZmVyKTsKZGlmZiAtLWdpdCBhL3NyYy90aHJlYWQuYyBiL3Ny Yy90aHJlYWQuYwppbmRleCA4ZmQ3MTNkMGM4MS4uY2UxZWNmMjJjYTkgMTAwNjQ0Ci0tLSBh L3NyYy90aHJlYWQuYworKysgYi9zcmMvdGhyZWFkLmMKQEAgLTg4MiwxMSArODgyLDE4IEBA IGZpbmFsaXplX29uZV90aHJlYWQgKHN0cnVjdCB0aHJlYWRfc3RhdGUgKnN0YXRlKQogICBm cmVlX2JjX3RocmVhZCAoJnN0YXRlLT5iYyk7CiB9CiAKLURFRlVOICgibWFrZS10aHJlYWQi LCBGbWFrZV90aHJlYWQsIFNtYWtlX3RocmVhZCwgMSwgMiwgMCwKK0RFRlVOICgibWFrZS10 aHJlYWQiLCBGbWFrZV90aHJlYWQsIFNtYWtlX3RocmVhZCwgMSwgMywgMCwKICAgICAgICBk b2M6IC8qIFN0YXJ0IGEgbmV3IHRocmVhZCBhbmQgcnVuIEZVTkNUSU9OIGluIGl0LgogV2hl biB0aGUgZnVuY3Rpb24gZXhpdHMsIHRoZSB0aHJlYWQgZGllcy4KLUlmIE5BTUUgaXMgZ2l2 ZW4sIGl0IG11c3QgYmUgYSBzdHJpbmc7IGl0IG5hbWVzIHRoZSBuZXcgdGhyZWFkLiAgKi8p Ci0gIChMaXNwX09iamVjdCBmdW5jdGlvbiwgTGlzcF9PYmplY3QgbmFtZSkKK0lmIE5BTUUg aXMgZ2l2ZW4sIGl0IG11c3QgYmUgYSBzdHJpbmc7IGl0IG5hbWVzIHRoZSBuZXcgdGhyZWFk LgorCitCVUZGRVItRElTUE9TSVRJT04gZGV0ZXJtaW5lcyBob3cgYXR0YWNoZWQgdGhlIHRo cmVhZCBpcyB0byBpdHMgY3VycmVudAorYnVmZmVyLiAgSWYgdGhlIHZhbHVlIGlzIHQsIHRo YXQgYnVmZmVyIGNhbid0IGJlIGtpbGxlZC4gIEFueSBvdGhlcgordmFsdWUsIGluY2x1ZGlu ZyBuaWwgKHRoZSBkZWZhdWx0KSwgbWVhbnMgdGhhdCBpZiBpdHMgYnVmZmVyIGlzIGtpbGxl ZCwKK3RoZSB0aHJlYWQgaXMgc3dpdGNoZWQgdG8gYW5vdGhlciBidWZmZXIgYW5kIHJlY2Vp dmVzIGFuIGVycm9yIHNpZ25hbAorYHRocmVhZC1idWZmZXIta2lsbGVkJy4gIEJ1dCBpZiB0 aGUgdmFsdWUgaXMgc3ltYm9sIGBzaWxlbnRseScsIG5vIGVycm9yCit3aWxsIGJlIHNpZ25h bGVkLiAgKi8pCisgIChMaXNwX09iamVjdCBmdW5jdGlvbiwgTGlzcF9PYmplY3QgbmFtZSwg TGlzcF9PYmplY3QgYnVmZmVyX2Rpc3Bvc2l0aW9uKQogewogICAvKiBDYW4ndCBzdGFydCBh IHRocmVhZCBpbiB0ZW1hY3MuICAqLwogICBpZiAoIWluaXRpYWxpemVkKQpAQCAtOTM0LDYg Kzk0MSw4IEBAIERFRlVOICgibWFrZS10aHJlYWQiLCBGbWFrZV90aHJlYWQsIFNtYWtlX3Ro cmVhZCwgMSwgMiwgMCwKICNlbmRpZgogICAgIH0KIAorICBuZXdfdGhyZWFkLT5idWZmZXJf ZGlzcG9zaXRpb24gPSBidWZmZXJfZGlzcG9zaXRpb247CisKICAgLyogRklYTUU6IHJhY2Ug aGVyZSB3aGVyZSBuZXcgdGhyZWFkIG1pZ2h0IG5vdCBiZSBmaWxsZWQgaW4/ICAqLwogICBM aXNwX09iamVjdCByZXN1bHQ7CiAgIFhTRVRUSFJFQUQgKHJlc3VsdCwgbmV3X3RocmVhZCk7 CkBAIC05NzIsNiArOTgxLDE1IEBAIHRocmVhZF9zaWduYWxfY2FsbGJhY2sgKHZvaWQgKmFy ZykKICAgcG9zdF9hY3F1aXJlX2dsb2JhbF9sb2NrIChzZWxmKTsKIH0KIAorc3RhdGljIHZv aWQKK3RocmVhZF9zZXRfZXJyb3IgKHN0cnVjdCB0aHJlYWRfc3RhdGUgKnRzdGF0ZSwgTGlz cF9PYmplY3QgZXJyb3Jfc3ltYm9sLCBMaXNwX09iamVjdCBkYXRhKQoreworICAvKiBXaGF0 IHRvIGRvIGlmIHRocmVhZCBpcyBhbHJlYWR5IHNpZ25hbGVkPyAgKi8KKyAgLyogV2hhdCBp ZiBlcnJvcl9zeW1ib2wgaXMgUW5pbD8gICovCisgIHRzdGF0ZS0+ZXJyb3Jfc3ltYm9sID0g ZXJyb3Jfc3ltYm9sOworICB0c3RhdGUtPmVycm9yX2RhdGEgPSBkYXRhOworfQorCiBERUZV TiAoInRocmVhZC1zaWduYWwiLCBGdGhyZWFkX3NpZ25hbCwgU3RocmVhZF9zaWduYWwsIDMs IDMsIDAsCiAgICAgICAgZG9jOiAvKiBTaWduYWwgYW4gZXJyb3IgaW4gYSB0aHJlYWQuCiBU aGlzIGFjdHMgbGlrZSBgc2lnbmFsJywgYnV0IGFycmFuZ2VzIGZvciB0aGUgc2lnbmFsIHRv IGJlIHJhaXNlZApAQCAtMTAwNiwxMCArMTAyNCw3IEBAIERFRlVOICgidGhyZWFkLXNpZ25h bCIsIEZ0aHJlYWRfc2lnbmFsLCBTdGhyZWFkX3NpZ25hbCwgMywgMywgMCwKICAgZWxzZQog I2VuZGlmCiAgICAgewotICAgICAgLyogV2hhdCB0byBkbyBpZiB0aHJlYWQgaXMgYWxyZWFk eSBzaWduYWxlZD8gICovCi0gICAgICAvKiBXaGF0IGlmIGVycm9yX3N5bWJvbCBpcyBRbmls PyAgKi8KLSAgICAgIHRzdGF0ZS0+ZXJyb3Jfc3ltYm9sID0gZXJyb3Jfc3ltYm9sOwotICAg ICAgdHN0YXRlLT5lcnJvcl9kYXRhID0gZGF0YTsKKyAgICAgIHRocmVhZF9zZXRfZXJyb3Ig KHRzdGF0ZSwgZXJyb3Jfc3ltYm9sLCBkYXRhKTsKIAogICAgICAgaWYgKHRzdGF0ZS0+d2Fp dF9jb25kdmFyKQogCWZsdXNoX3N0YWNrX2NhbGxfZnVuYyAodGhyZWFkX3NpZ25hbF9jYWxs YmFjaywgdHN0YXRlKTsKQEAgLTEwMzAsNiArMTA0NSwzNCBAQCBERUZVTiAoInRocmVhZC1s aXZlLXAiLCBGdGhyZWFkX2xpdmVfcCwgU3RocmVhZF9saXZlX3AsIDEsIDEsIDAsCiAgIHJl dHVybiB0aHJlYWRfbGl2ZV9wICh0c3RhdGUpID8gUXQgOiBRbmlsOwogfQogCitERUZVTiAo InRocmVhZC1idWZmZXItZGlzcG9zaXRpb24iLCBGdGhyZWFkX2J1ZmZlcl9kaXNwb3NpdGlv biwgU3RocmVhZF9idWZmZXJfZGlzcG9zaXRpb24sCisgICAgICAgMSwgMSwgMCwKKyAgICAg ICBkb2M6IC8qIFJldHVybiB0aGUgdmFsdWUgb2YgVEhSRUFEJ3MgYnVmZmVyIGRpc3Bvc2l0 aW9uLiAgKi8pCisgIChMaXNwX09iamVjdCB0aHJlYWQpCit7CisgIHN0cnVjdCB0aHJlYWRf c3RhdGUgKnRzdGF0ZTsKKworICBDSEVDS19USFJFQUQgKHRocmVhZCk7CisgIHRzdGF0ZSA9 IFhUSFJFQUQgKHRocmVhZCk7CisKKyAgcmV0dXJuIHRzdGF0ZS0+YnVmZmVyX2Rpc3Bvc2l0 aW9uOworfQorCitERUZVTiAoInRocmVhZC1zZXQtYnVmZmVyLWRpc3Bvc2l0aW9uIiwgRnRo cmVhZF9zZXRfYnVmZmVyX2Rpc3Bvc2l0aW9uLCBTdGhyZWFkX3NldF9idWZmZXJfZGlzcG9z aXRpb24sCisgICAgICAgMiwgMiwgMCwKKyAgICAgICBkb2M6IC8qIFNldCBUSFJFQUQncyBi dWZmZXIgZGlzcG9zaXRpb24uICAqLykKKyAgKExpc3BfT2JqZWN0IHRocmVhZCwgTGlzcF9P YmplY3QgdmFsdWUpCit7CisgIHN0cnVjdCB0aHJlYWRfc3RhdGUgKnRzdGF0ZTsKKworICBD SEVDS19USFJFQUQgKHRocmVhZCk7CisgIHRzdGF0ZSA9IFhUSFJFQUQgKHRocmVhZCk7CisK KyAgdHN0YXRlLT5idWZmZXJfZGlzcG9zaXRpb24gPSB2YWx1ZTsKKworICByZXR1cm4gdmFs dWU7Cit9CisKIERFRlVOICgidGhyZWFkLS1ibG9ja2VyIiwgRnRocmVhZF9ibG9ja2VyLCBT dGhyZWFkX2Jsb2NrZXIsIDEsIDEsIDAsCiAgICAgICAgZG9jOiAvKiBSZXR1cm4gdGhlIG9i amVjdCB0aGF0IFRIUkVBRCBpcyBibG9ja2luZyBvbi4KIElmIFRIUkVBRCBpcyBibG9ja2Vk IGluIGB0aHJlYWQtam9pbicgb24gYSBzZWNvbmQgdGhyZWFkLCByZXR1cm4gdGhhdApAQCAt MTEzOSwxMyArMTE4Miw0MyBAQCB0aHJlYWRfY2hlY2tfY3VycmVudF9idWZmZXIgKHN0cnVj dCBidWZmZXIgKmJ1ZmZlcikKICAgICAgIGlmIChpdGVyID09IGN1cnJlbnRfdGhyZWFkKQog CWNvbnRpbnVlOwogCi0gICAgICBpZiAoaXRlci0+bV9jdXJyZW50X2J1ZmZlciA9PSBidWZm ZXIpCisgICAgICBpZiAoaXRlci0+bV9jdXJyZW50X2J1ZmZlciA9PSBidWZmZXIgJiYgRVEg KGl0ZXItPmJ1ZmZlcl9kaXNwb3NpdGlvbiwgUXQpKQogCXJldHVybiB0cnVlOwogICAgIH0K IAogICByZXR1cm4gZmFsc2U7CiB9CiAKK3ZvaWQKK3RocmVhZF9hbGxfYmVmb3JlX2J1ZmZl cl9raWxsZWQgKExpc3BfT2JqZWN0IGN1cnJlbnQpCit7CisgIHN0cnVjdCB0aHJlYWRfc3Rh dGUgKml0ZXI7CisgIHN0cnVjdCBidWZmZXIgKiBvdGhlciA9IE5VTEw7CisgIHN0cnVjdCBi dWZmZXIgKiBiID0gWEJVRkZFUiAoY3VycmVudCk7CisgIHN0cnVjdCB0aHJlYWRfc3RhdGUg KmNhbGxlcl90aHJlYWQgPSBjdXJyZW50X3RocmVhZDsKKworICBmb3IgKGl0ZXIgPSBhbGxf dGhyZWFkczsgaXRlcjsgaXRlciA9IGl0ZXItPm5leHRfdGhyZWFkKQorICAgIHsKKyAgICAg IGlmIChpdGVyID09IGNhbGxlcl90aHJlYWQpCisJY29udGludWU7CisKKyAgICAgIGlmIChp dGVyLT5tX2N1cnJlbnRfYnVmZmVyID09IGIpCisJeworCSAgTGlzcF9PYmplY3QgdGhyZWFk OworCisJICBYU0VUVEhSRUFEICh0aHJlYWQsIGl0ZXIpOworCisJICBpZiAob3RoZXIgPT0g TlVMTCkKKwkgICAgb3RoZXIgPSBYQlVGRkVSIChGb3RoZXJfYnVmZmVyIChjdXJyZW50LCBR bmlsLCBRbmlsKSk7CisKKwkgIGlmICghRVEgKGl0ZXItPmJ1ZmZlcl9kaXNwb3NpdGlvbiwg UXNpbGVudGx5KSkKKwkgICAgdGhyZWFkX3NldF9lcnJvciAoaXRlciwgUXRocmVhZF9idWZm ZXJfa2lsbGVkLCBRbmlsKTsKKworCSAgaXRlci0+bV9jdXJyZW50X2J1ZmZlciA9IG90aGVy OworCX0KKyAgICB9Cit9CisKIAwKIAogYm9vbApAQCAtMTE3NCw2ICsxMjQ3LDcgQEAgaW5p dF90aHJlYWRzICh2b2lkKQogI2VuZGlmIC8qIGRlZmluZWQgSEFWRV9BTkRST0lEICYmICFk ZWZpbmVkIEFORFJPSURfU1RVQklGWSAqLwogCiAgIG1haW5fdGhyZWFkLnMudGhyZWFkX2lk ID0gc3lzX3RocmVhZF9zZWxmICgpOworICBtYWluX3RocmVhZC5zLmJ1ZmZlcl9kaXNwb3Np dGlvbiA9IFFuaWw7CiAgIGluaXRfYmNfdGhyZWFkICgmbWFpbl90aHJlYWQucy5iYyk7CiB9 CiAKQEAgLTEyMDMsNiArMTI3Nyw4IEBAIHN5bXNfb2ZfdGhyZWFkcyAodm9pZCkKICAgICAg IGRlZnN1YnIgKCZTY29uZGl0aW9uX211dGV4KTsKICAgICAgIGRlZnN1YnIgKCZTY29uZGl0 aW9uX25hbWUpOwogICAgICAgZGVmc3ViciAoJlN0aHJlYWRfbGFzdF9lcnJvcik7CisgICAg ICBkZWZzdWJyICgmU3RocmVhZF9idWZmZXJfZGlzcG9zaXRpb24pOworICAgICAgZGVmc3Vi ciAoJlN0aHJlYWRfc2V0X2J1ZmZlcl9kaXNwb3NpdGlvbik7CiAKICAgICAgIHN0YXRpY3By byAoJmxhc3RfdGhyZWFkX2Vycm9yKTsKICAgICAgIGxhc3RfdGhyZWFkX2Vycm9yID0gUW5p bDsKQEAgLTEyMTQsNiArMTI5MCwxMyBAQCBzeW1zX29mX3RocmVhZHMgKHZvaWQpCiAgIERF RlNZTSAoUW11dGV4cCwgIm11dGV4cCIpOwogICBERUZTWU0gKFFjb25kaXRpb25fdmFyaWFi bGVfcCwgImNvbmRpdGlvbi12YXJpYWJsZS1wIik7CiAKKyAgREVGU1lNIChRdGhyZWFkX2J1 ZmZlcl9raWxsZWQsICJ0aHJlYWQtYnVmZmVyLWtpbGxlZCIpOworICBGcHV0IChRdGhyZWFk X2J1ZmZlcl9raWxsZWQsIFFlcnJvcl9jb25kaXRpb25zLAorCWxpc3QgKFF0aHJlYWRfYnVm ZmVyX2tpbGxlZCwgUWVycm9yKSk7CisgIEZwdXQgKFF0aHJlYWRfYnVmZmVyX2tpbGxlZCwg UWVycm9yX21lc3NhZ2UsCisJYnVpbGRfc3RyaW5nICgiVGhyZWFkJ3MgY3VycmVudCBidWZm ZXIga2lsbGVkIikpOworICBERUZTWU0gKFFzaWxlbnRseSwgInNpbGVudGx5Iik7CisKICAg REVGVkFSX0xJU1AgKCJtYWluLXRocmVhZCIsIFZtYWluX3RocmVhZCwKICAgICBkb2M6IC8q IFRoZSBtYWluIHRocmVhZCBvZiBFbWFjcy4gICovKTsKICNpZmRlZiBUSFJFQURTX0VOQUJM RUQKZGlmZiAtLWdpdCBhL3NyYy90aHJlYWQuaCBiL3NyYy90aHJlYWQuaAppbmRleCBjNDk2 NDUzYjA5MC4uMzIwYTNlMzFkZjQgMTAwNjQ0Ci0tLSBhL3NyYy90aHJlYWQuaAorKysgYi9z cmMvdGhyZWFkLmgKQEAgLTE0Myw2ICsxNDMsOSBAQCAjZGVmaW5lIGxpc3BfZXZhbF9kZXB0 aCAoY3VycmVudF90aHJlYWQtPm1fbGlzcF9ldmFsX2RlcHRoKQogICBzdHJ1Y3QgYnVmZmVy ICptX2N1cnJlbnRfYnVmZmVyOwogI2RlZmluZSBjdXJyZW50X2J1ZmZlciAoY3VycmVudF90 aHJlYWQtPm1fY3VycmVudF9idWZmZXIpCiAKKyAgLyogRGVjaWRlcyB3aGV0aGVyIHRoZSB0 aHJlYWQncyBjdXJyZW50IGJ1ZmZlciBjYW4gYmUga2lsbGVkLiAgKi8KKyAgTGlzcF9PYmpl Y3QgYnVmZmVyX2Rpc3Bvc2l0aW9uOworCiAgIC8qIEV2ZXJ5IGNhbGwgdG8gcmVfc2VhcmNo LCBldGMuLCBtdXN0IHBhc3MgJnNlYXJjaF9yZWdzIGFzIHRoZSByZWdzCiAgICAgIGFyZ3Vt ZW50IHVubGVzcyB5b3UgY2FuIHNob3cgaXQgaXMgdW5uZWNlc3NhcnkgKGkuZS4sIGlmIHJl X3NlYXJjaAogICAgICBpcyBjZXJ0YWlubHkgZ29pbmcgdG8gYmUgY2FsbGVkIGFnYWluIGJl Zm9yZSByZWdpb24tYXJvdW5kLW1hdGNoCkBAIC0zMzgsNiArMzQxLDggQEAgWENPTkRWQVIg KExpc3BfT2JqZWN0IGEpCiAKIGJvb2wgdGhyZWFkX2NoZWNrX2N1cnJlbnRfYnVmZmVyIChz dHJ1Y3QgYnVmZmVyICopOwogCit2b2lkIHRocmVhZF9hbGxfYmVmb3JlX2J1ZmZlcl9raWxs ZWQgKExpc3BfT2JqZWN0IGJ1ZmZlcik7CisKIElOTElORV9IRUFERVJfRU5ECiAKICNlbmRp ZiAvKiBUSFJFQURfSCAqLwpkaWZmIC0tZ2l0IGEvdGVzdC9zcmMvdGhyZWFkLXRlc3RzLmVs IGIvdGVzdC9zcmMvdGhyZWFkLXRlc3RzLmVsCmluZGV4IDlhMDY1MTg3YjVlLi4wZjc5OTlh ZjcxYSAxMDA2NDQKLS0tIGEvdGVzdC9zcmMvdGhyZWFkLXRlc3RzLmVsCisrKyBiL3Rlc3Qv c3JjL3RocmVhZC10ZXN0cy5lbApAQCAtMzk4LDYgKzM5OCw1NSBAQCB0aHJlYWRzLXRlc3Qt YnVnMzMwNzMKICAgKGxldCAoKHRoIChtYWtlLXRocmVhZCAnaWdub3JlKSkpCiAgICAgKHNo b3VsZC1ub3QgKGVxdWFsIHRoIG1haW4tdGhyZWFkKSkpKQogCisoZXJ0LWRlZnRlc3QgdGhy ZWFkLWJ1ZmZlci1kaXNwb3NpdGlvbi10ICgpCisgICJUZXN0IG5vdCBiZWluZyBhYmxlIHRv IGtpbGwgYSBiZyB0aHJlYWQncyBidWZmZXIuIgorICAoc2tpcC11bmxlc3MgKGZlYXR1cmVw ICd0aHJlYWRzKSkKKyAgKGxldCAoKGJ1ZiAoZ2V0LWJ1ZmZlci1jcmVhdGUgIiAqdGhyZWFk LWJ1ZmZlci1raWxsYWJsZS1uaWwqIikpCisgICAgICAgIHRocmVhZCkKKyAgICAod2l0aC1j dXJyZW50LWJ1ZmZlciBidWYKKyAgICAgIChzZXRxIHRocmVhZAorICAgICAgICAgICAgKG1h a2UtdGhyZWFkCisgICAgICAgICAgICAgKGxhbWJkYSAoKQorICAgICAgICAgICAgICAgKHNs ZWVwLWZvciAwLjEpKQorICAgICAgICAgICAgIG5pbAorICAgICAgICAgICAgIHQpKSkKKyAg ICAoa2lsbC1idWZmZXIgYnVmKQorICAgIChzaG91bGQgKGJ1ZmZlci1saXZlLXAgYnVmKSkK KyAgICA7OyBObyBlcnJvcjoKKyAgICAodGhyZWFkLWpvaW4gdGhyZWFkKSkpCisKKyhlcnQt ZGVmdGVzdCB0aHJlYWQtYnVmZmVyLWRpc3Bvc2l0aW9uLW5pbCAoKQorICAiVGVzdCBraWxs aW5nIGEgYmcgdGhyZWFkJ3MgYnVmZmVyLiIKKyAgKHNraXAtdW5sZXNzIChmZWF0dXJlcCAn dGhyZWFkcykpCisgIChsZXQgKChidWYgKGdldC1idWZmZXItY3JlYXRlICIgKnRocmVhZC1i dWZmZXIta2lsbGFibGUtdCoiKSkKKyAgICAgICAgdGhyZWFkKQorICAgICh3aXRoLWN1cnJl bnQtYnVmZmVyIGJ1ZgorICAgICAgKHNldHEgdGhyZWFkCisgICAgICAgICAgICAobWFrZS10 aHJlYWQKKyAgICAgICAgICAgICAobGFtYmRhICgpCisgICAgICAgICAgICAgICAoc2xlZXAt Zm9yIDAuMSkpKSkpCisgICAgKGtpbGwtYnVmZmVyIGJ1ZikKKyAgICAoc2hvdWxkLW5vdCAo YnVmZmVyLWxpdmUtcCBidWYpKQorICAgIChzaG91bGQtZXJyb3IKKyAgICAgKHRocmVhZC1q b2luIHRocmVhZCkKKyAgICAgOnR5cGUgJ3RocmVhZC1idWZmZXIta2lsbGVkKSkpCisKKyhl cnQtZGVmdGVzdCB0aHJlYWQtYnVmZmVyLWRpc3Bvc2l0aW9uLXNpbGVudGx5ICgpCisgICJU ZXN0IGtpbGxpbmcgYSBiZyB0aHJlYWQncyBidWZmZXIgc2lsZW50bHkuIgorICAoc2tpcC11 bmxlc3MgKGZlYXR1cmVwICd0aHJlYWRzKSkKKyAgKGxldCAoKGJ1ZiAoZ2V0LWJ1ZmZlci1j cmVhdGUgIiAqdGhyZWFkLWJ1ZmZlci1raWxsYWJsZS10KiIpKQorICAgICAgICB0aHJlYWQp CisgICAgKHdpdGgtY3VycmVudC1idWZmZXIgYnVmCisgICAgICAoc2V0cSB0aHJlYWQKKyAg ICAgICAgICAgIChtYWtlLXRocmVhZAorICAgICAgICAgICAgIChsYW1iZGEgKCkKKyAgICAg ICAgICAgICAgIChzbGVlcC1mb3IgMC4xKSkKKyAgICAgICAgICAgICBuaWwKKyAgICAgICAg ICAgICAnc2lsZW50bHkpKSkKKyAgICAoa2lsbC1idWZmZXIgYnVmKQorICAgIChzaG91bGQt bm90IChidWZmZXItbGl2ZS1wIGJ1ZikpCisgICAgKHRocmVhZC1qb2luIHRocmVhZCkpKQor CiAoZGVmdmFyIHRocmVhZHMtdGVzdC0tdmFyICdnbG9iYWwpCiAKIChlcnQtZGVmdGVzdCB0 aHJlYWRzLXRlc3QtYnVnNDg5OTAgKCkK --------------GdOYfT9QjY4pXTdBUIgPTGhb-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 24 02:42:36 2025 Received: (at 76969) by debbugs.gnu.org; 24 Jul 2025 06:42:36 +0000 Received: from localhost ([127.0.0.1]:54233 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uepf2-0004b1-2E for submit@debbugs.gnu.org; Thu, 24 Jul 2025 02:42:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46882) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uepez-0004ak-Oz for 76969@debbugs.gnu.org; Thu, 24 Jul 2025 02:42:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uepet-0001QQ-Qb; Thu, 24 Jul 2025 02:42:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=pWQfQcqjV5ip/mNQkRVOIDdW1vvpykwlL2SRLpFLB2w=; b=dc4q0wDA3rhe sM9xe2PS6eo7EYBjMIrr9EuKrk6IEEWF4bzAHfHQqnG3QVI7FAUuTdFMCgaKhokfzP/PD5ww/2kmW WUWKg2KtFPkl2K9dP9yV6MVPIXUowAl1x/+IFNlpc1MGkxhLitnDj/CayW5O1fwmZqszn4/KAImSg U+CPGyFWO+Hx0EXyQPgbSL+T2XDug+3p6bjzxiPguvNI9eMHX/1y6/vX3fXz347Ls1Qh4kFA5Q0hj eCHr808+osPOFYaCpNmx69VvJUHsd2Jb59GTky6qQDGgqYGAd2oytz/ZFYfuBkubkRIXo8MMM4dhJ w3eMBl4hmOK+T04glAQzQA==; Date: Thu, 24 Jul 2025 09:42:24 +0300 Message-Id: <86wm7y5bu7.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Wed, 23 Jul 2025 16:41:42 -0400) Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current References: <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> <86y0x3qwbk.fsf@gnu.org> <7754f678-6c8e-4045-8c3d-e2b39680f023@gutov.dev> <54677c11-0274-443c-b2b1-079d73e34d10@gutov.dev> <86wm87gwpi.fsf@gnu.org> <9222ba4e-9a3b-4137-ae31-6796c1838d3c@gutov.dev> <86pldyf23h.fsf@gnu.org> <4a54a7ec-1d38-4d8b-be7f-e7e0ea55d94f@gutov.dev> <86ikjk9yio.fsf@gnu.org> <485bb371-7452-4ff4-9727-2397f7cc6993@gutov.dev> <86o6tb6svf.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76969 Cc: dmitry@gutov.dev, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: Dmitry Gutov , 76969@debbugs.gnu.org > Date: Wed, 23 Jul 2025 16:41:42 -0400 > > Eli Zaretskii writes: > > >> Are we okay with nil meaning "thread's buffer is killed and sent a > >> signal", t meaning "thread's buffer is never killed" and 'silently' > >> meaning "thread's buffer is killed without a signal"? > > > > Maybe. I'm not sure there's a definite agreement about the default. > > Just as one vote, I'm in favor of "thread's buffer is killed and sent a > signal" being the default behavior. Thanks, but would you please explain why this is your opinion? IOW, how is this better from, say, the current behavior of not killing the buffer? From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 26 06:07:08 2025 Received: (at 76969) by debbugs.gnu.org; 26 Jul 2025 10:07:08 +0000 Received: from localhost ([127.0.0.1]:40170 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ufbo4-0006bK-17 for submit@debbugs.gnu.org; Sat, 26 Jul 2025 06:07:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45926) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ufbo1-0006aX-Oe for 76969@debbugs.gnu.org; Sat, 26 Jul 2025 06:07:06 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ufbnw-0007tq-6c; Sat, 26 Jul 2025 06:07:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=oUTkZUDunuDpfqOOK9cxJL/nuniD1jNe07/jJZeED/0=; b=P547YF8q2n2j UtG5wCtJqGjqoroOc5G4q2FDfifgkd35eoBBIDRMNY18Q9wzv75DYQRZOxo9BWLjdI0qWlI7mtXL+ 0CxwIga6h9kyWYGXmxMTukMJWVDm0al/kH1TFyUvfLIaM8bw/o8RA73R/EDk23kvnV2NAvEkpSh9k 1LDAzvFZlOW+tWSKaSQYTcaxP4V4swBPV8vPhUVxjYh1pSasZmdic311jjkUyc2Pigl327BvYvlem ehUvYUN57x0nbt2WFBg2w5XA3cyTKzsDnuvSg8FjmTlfaOUfTOEJ//q0w6puqVTSuB+2F6hepw5Ii bXR6oxGm6X8xLpVW/GlOHQ==; Date: Sat, 26 Jul 2025 13:06:57 +0300 Message-Id: <867bzv1d1a.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Thu, 24 Jul 2025 04:32:05 +0300) Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current References: <86senh2ren.fsf@gnu.org> <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> <86y0x3qwbk.fsf@gnu.org> <7754f678-6c8e-4045-8c3d-e2b39680f023@gutov.dev> <54677c11-0274-443c-b2b1-079d73e34d10@gutov.dev> <86wm87gwpi.fsf@gnu.org> <9222ba4e-9a3b-4137-ae31-6796c1838d3c@gutov.dev> <86pldyf23h.fsf@gnu.org> <4a54a7ec-1d38-4d8b-be7f-e7e0ea55d94f@gutov.dev> <86ikjk9yio.fsf@gnu.org> <485bb371-7452-4ff4-9727-2397f7cc6993@gutov.dev> <86o6tb6svf.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 24 Jul 2025 04:32:05 +0300 > Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org > From: Dmitry Gutov > > +DEFUN ("thread-buffer-disposition", Fthread_buffer_disposition, Sthread_buffer_disposition, > + 1, 1, 0, > + doc: /* Return the value of THREAD's buffer disposition. */) The doc string should document the values. > +DEFUN ("thread-set-buffer-disposition", Fthread_set_buffer_disposition, Sthread_set_buffer_disposition, > + 2, 2, 0, > + doc: /* Set THREAD's buffer disposition. */) Likewise. Also, these two new primitives should be documented in the ELisp manual. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 30 22:43:43 2025 Received: (at 76969) by debbugs.gnu.org; 31 Jul 2025 02:43:43 +0000 Received: from localhost ([127.0.0.1]:44442 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhJGh-0003Ql-9w for submit@debbugs.gnu.org; Wed, 30 Jul 2025 22:43:43 -0400 Received: from fhigh-a2-smtp.messagingengine.com ([103.168.172.153]:59919) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uhJGe-0003QO-7H for 76969@debbugs.gnu.org; Wed, 30 Jul 2025 22:43:40 -0400 Received: from phl-compute-12.internal (phl-compute-12.phl.internal [10.202.2.52]) by mailfhigh.phl.internal (Postfix) with ESMTP id B7BAB140026B; Wed, 30 Jul 2025 22:43:34 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-12.internal (MEProxy); Wed, 30 Jul 2025 22:43:34 -0400 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=1753929814; x=1754016214; bh=z54Eaoeq3qhiGKlnal7p5dYaUdNvUaTn5gmcKQsxh3c=; b= q8XtGrw3nu7FYCr3oJkullS7Lp4EeuZJb6ekV9k/aSdZ1zX+EikzXC3WJqUrCKSR LCvrndaRCokqxBVH+pKkDnbiMNVNW507r5ZhE+HEvST5Bzey/CqgX0NNZ4sz57qB EQrTnQXUPtuQZD2Fihs+rsRCY86CERsuJhfGt3JgKMz7LCmVB3YwBgUOjmlmtZ5j 9QKIKtWY8TxeQBdg5Xl4WEGJW0NgX7jucQNsFbstXtt8kNDyFxCZSKm0d7Wu2rDV +qqyJ2Tfs3+ru5dz+y03f3bTNxSS+HcUiLwXNPG5t/Kapst8zbJsSufm/6JALmYj FL0630AnfVk5ww8JgL6ziQ== 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=1753929814; x= 1754016214; bh=z54Eaoeq3qhiGKlnal7p5dYaUdNvUaTn5gmcKQsxh3c=; b=h R9tXYKbM8pOtFEoolREvehh0AWQn++kORmqqEPIMDzte0KUiWN7uZEXBLABRY008 U0ZqOe5dsXBdX/KY1Rt5cOuHRN5JGj1aT16d6vzJAPqX5/xY2tnNRuz5jyT52MzN qMZWmo0ZXg5buGMI52OiLD0Vh1smw6B8OFa15U+hbMqIAs3T8EesNJ60TOiHH7ct uacCUgSb6/SxyScYGx1pw8XD1byZVb7g4ilybw51lEtwaTigvAKYvOJfKaBpAD5Y ws2aSncgAEWAuRelkHMEUWE2OzqDxWEo3KnJ1eQTW7WAuRfJMtTq4maPm0Ou1jRz +Oh91cMhZMn+YqbrjjLnQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdelleeigecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihhtrhih ucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtthgvrh hnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudejheen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhith hrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohepshgsrghugh hhsehjrghnvghsthhrvggvthdrtghomhdprhgtphhtthhopeejieelieelseguvggssghu ghhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 30 Jul 2025 22:43:33 -0400 (EDT) Message-ID: Date: Thu, 31 Jul 2025 05:43:30 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current To: Eli Zaretskii References: <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> <86y0x3qwbk.fsf@gnu.org> <7754f678-6c8e-4045-8c3d-e2b39680f023@gutov.dev> <54677c11-0274-443c-b2b1-079d73e34d10@gutov.dev> <86wm87gwpi.fsf@gnu.org> <9222ba4e-9a3b-4137-ae31-6796c1838d3c@gutov.dev> <86pldyf23h.fsf@gnu.org> <4a54a7ec-1d38-4d8b-be7f-e7e0ea55d94f@gutov.dev> <86ikjk9yio.fsf@gnu.org> <485bb371-7452-4ff4-9727-2397f7cc6993@gutov.dev> <86o6tb6svf.fsf@gnu.org> <867bzv1d1a.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <867bzv1d1a.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 26/07/2025 13:06, Eli Zaretskii wrote: >> Date: Thu, 24 Jul 2025 04:32:05 +0300 >> Cc:sbaugh@janestreet.com,76969@debbugs.gnu.org >> From: Dmitry Gutov >> >> +DEFUN ("thread-buffer-disposition", Fthread_buffer_disposition, Sthread_buffer_disposition, >> + 1, 1, 0, >> + doc: /* Return the value of THREAD's buffer disposition. */) > The doc string should document the values. > >> +DEFUN ("thread-set-buffer-disposition", Fthread_set_buffer_disposition, Sthread_set_buffer_disposition, >> + 2, 2, 0, >> + doc: /* Set THREAD's buffer disposition. */) > Likewise. Okay. Do I just copy the argument's description twice? Alternatively, could add references to 'make-thread'. > Also, these two new primitives should be documented in the ELisp > manual. Are they important enough for the manual? Since 'make-thread' gets the new argument, I'd imagine most users would go through it, or at least learn about "thread disposition" due to that. If you're sure, no problem - it's just the section that I'm looking at is called "Basic Thread Functions". From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 31 01:24:37 2025 Received: (at 76969) by debbugs.gnu.org; 31 Jul 2025 05:24:37 +0000 Received: from localhost ([127.0.0.1]:45326 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhLmP-00068m-4t for submit@debbugs.gnu.org; Thu, 31 Jul 2025 01:24:37 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60866) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uhLmM-00068M-QA for 76969@debbugs.gnu.org; Thu, 31 Jul 2025 01:24:35 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uhLmG-0004xl-Ra; Thu, 31 Jul 2025 01:24:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=sgvh+fFmOzZK6ilOwEmEGs5WNK8Ty2qbCBKfHWW/JQI=; b=QmACzjA11tT5 odsC4tKfrjqs9QI9PvM2UAo47W2HLDyqm7Behazx+h2HbdAhYaIIJlDrrAW9MfYjmhOD344DfHLW/ sLVGIwVupARuflavun6/qiP9ZhrFYK7Tc2cruQbG7dip2yi3UKXUquxdULi70PzxIHd4ehCttoC+4 +340xA5VMxiHHqI6LdgOOT1p0j4lp0K15/nC845mra6VobsjugJIuoAArtZ/JKjZMzxRXBn2mjVH/ slwHxAH3zmj/KnEY+oND0ZoiF99VZ7nGS1euFiRKD+kYfvqHES0fdOaKGWrmQGVvjUyVP4lFFxVnq y0wcBeKwojtHJs2cpp+bYA==; Date: Thu, 31 Jul 2025 08:24:26 +0300 Message-Id: <86cy9hue45.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Thu, 31 Jul 2025 05:43:30 +0300) Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current References: <15badabb-b95d-4c32-b5d5-4b98fa8db528@gutov.dev> <86wmct0yfj.fsf@gnu.org> <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> <86y0x3qwbk.fsf@gnu.org> <7754f678-6c8e-4045-8c3d-e2b39680f023@gutov.dev> <54677c11-0274-443c-b2b1-079d73e34d10@gutov.dev> <86wm87gwpi.fsf@gnu.org> <9222ba4e-9a3b-4137-ae31-6796c1838d3c@gutov.dev> <86pldyf23h.fsf@gnu.org> <4a54a7ec-1d38-4d8b-be7f-e7e0ea55d94f@gutov.dev> <86ikjk9yio.fsf@gnu.org> <485bb371-7452-4ff4-9727-2397f7cc6993@gutov.dev> <86o6tb6svf.fsf@gnu.org> <867bzv1d1a.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 31 Jul 2025 05:43:30 +0300 > Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org > From: Dmitry Gutov > > On 26/07/2025 13:06, Eli Zaretskii wrote: > >> Date: Thu, 24 Jul 2025 04:32:05 +0300 > >> Cc:sbaugh@janestreet.com,76969@debbugs.gnu.org > >> From: Dmitry Gutov > >> > >> +DEFUN ("thread-buffer-disposition", Fthread_buffer_disposition, Sthread_buffer_disposition, > >> + 1, 1, 0, > >> + doc: /* Return the value of THREAD's buffer disposition. */) > > The doc string should document the values. > > > >> +DEFUN ("thread-set-buffer-disposition", Fthread_set_buffer_disposition, Sthread_set_buffer_disposition, > >> + 2, 2, 0, > >> + doc: /* Set THREAD's buffer disposition. */) > > Likewise. > > Okay. Do I just copy the argument's description twice? Alternatively, > could add references to 'make-thread'. Either of these is fine. > > Also, these two new primitives should be documented in the ELisp > > manual. > > Are they important enough for the manual? Since 'make-thread' gets the > new argument, I'd imagine most users would go through it, or at least > learn about "thread disposition" due to that. It just takes a sentence or two (and index entries) to mention these. You don't have to use the full-fledged @defun thingy. > If you're sure, no problem - it's just the section that I'm looking at > is called "Basic Thread Functions". Right after make-thread, IMO. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 31 20:01:29 2025 Received: (at 76969) by debbugs.gnu.org; 1 Aug 2025 00:01:29 +0000 Received: from localhost ([127.0.0.1]:51550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhdDE-0002HR-KO for submit@debbugs.gnu.org; Thu, 31 Jul 2025 20:01:29 -0400 Received: from fout-a8-smtp.messagingengine.com ([103.168.172.151]:50195) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uhdD6-0002H8-VO for 76969@debbugs.gnu.org; Thu, 31 Jul 2025 20:01:25 -0400 Received: from phl-compute-06.internal (phl-compute-06.phl.internal [10.202.2.46]) by mailfout.phl.internal (Postfix) with ESMTP id 6740FEC018D; Thu, 31 Jul 2025 20:01:15 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Thu, 31 Jul 2025 20:01:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc: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=1754006475; x=1754092875; bh=SV9rihvR/w 4EQYI2/Bw3YMSw9nBbHux4I7rvrxh8Je0=; b=B6DL3nqHSB9g2woSUaG6xWtD3o xzy2EszRKuzHaqRQCytx7LwSELLFycBCf7c22C4fzv7kNuRy3KsFqREUZF4nkLar amQCpTGvRREL5zmbXsnRt2AMuD1uqbzrxNnbFk1fyWjopixU6Pch4YeMq0zPSgud BMUk6rgXT/S6PcP55PvfTYg0S+qf3ye2fgsQ4hKBX4fRM2H/LzUvB70e9N+79Tn3 aa5bcqR/95dQKRkZ5305Bn/uecoo+50DwxLmVeMoyyCTuKomwSPqtipf2p/ql8YA phvfH+XWSNhpn8sd1LU5dLzRYJKeqwKn4uuqRjpp0W/7ys/DnaK0HQ5KCvSg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc: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= 1754006475; x=1754092875; bh=SV9rihvR/w4EQYI2/Bw3YMSw9nBbHux4I7r vrxh8Je0=; b=K1pSpPVesbU90E5kjhtTtakbWZuDtN9uM7JsUum09Q5hThSKWIp E/UFHImeMDWbOugbm24LziNjyMfyYVtgCuZaDwSKzHVxsNS3nigXS1QGA8wi8yiX mpNeOCwLWNIYjSp5A6cf6VgkrYkqmdVfMOAoxZ2roBl9ZDfgxxsXxTm5puNHFe+b DucWYe2nmqwBySPAhC36cvl6KNo5vMziOFnzCAAnZ9c6exzLQWNhvM+rIFNtk9Y9 cNmDXq+muUtNa5raOmh8ZnWllxvu3FN6SUxCgUtn7K7/KnJXXfrZlYDOZbtpvMOe EOIjmBLmml3WtWvvrUhmRp6lkLs8ozcCfgQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgddutddvvddtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurheptgfkffggfgfuvfevfhfhjgesmhdtreertddvjeenucfhrhhomhepffhmihhtrhih ucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtthgvrh hnpeehleefudekudduveekieelgfeiffdvkefhkeeljeeujeegueekveffkeejjeevheen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhith hrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohepshgsrghugh hhsehjrghnvghsthhrvggvthdrtghomhdprhgtphhtthhopeejieelieelseguvggssghu ghhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 31 Jul 2025 20:01:13 -0400 (EDT) Content-Type: multipart/mixed; boundary="------------FLfbPOEvoTN10SUTseMFBdhv" Message-ID: <6b1ece75-663f-4855-ae1a-de7ee15a8103@gutov.dev> Date: Fri, 1 Aug 2025 03:01:11 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current To: Eli Zaretskii References: <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> <86y0x3qwbk.fsf@gnu.org> <7754f678-6c8e-4045-8c3d-e2b39680f023@gutov.dev> <54677c11-0274-443c-b2b1-079d73e34d10@gutov.dev> <86wm87gwpi.fsf@gnu.org> <9222ba4e-9a3b-4137-ae31-6796c1838d3c@gutov.dev> <86pldyf23h.fsf@gnu.org> <4a54a7ec-1d38-4d8b-be7f-e7e0ea55d94f@gutov.dev> <86ikjk9yio.fsf@gnu.org> <485bb371-7452-4ff4-9727-2397f7cc6993@gutov.dev> <86o6tb6svf.fsf@gnu.org> <867bzv1d1a.fsf@gnu.org> <86cy9hue45.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86cy9hue45.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) This is a multi-part message in MIME format. --------------FLfbPOEvoTN10SUTseMFBdhv Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 31/07/2025 08:24, Eli Zaretskii wrote: >> Okay. Do I just copy the argument's description twice? Alternatively, >> could add references to 'make-thread'. > Either of these is fine. > >>> Also, these two new primitives should be documented in the ELisp >>> manual. >> Are they important enough for the manual? Since 'make-thread' gets the >> new argument, I'd imagine most users would go through it, or at least >> learn about "thread disposition" due to that. > It just takes a sentence or two (and index entries) to mention these. > You don't have to use the full-fledged @defun thingy. > >> If you're sure, no problem - it's just the section that I'm looking at >> is called "Basic Thread Functions". > Right after make-thread, IMO. Great, updated. Also added main_thread_p check in thread-set-buffer-disposition. --------------FLfbPOEvoTN10SUTseMFBdhv Content-Type: text/x-patch; charset=UTF-8; name="thread-buffer-disposition-v2.diff" Content-Disposition: attachment; filename="thread-buffer-disposition-v2.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2RvYy9saXNwcmVmL3RocmVhZHMudGV4aSBiL2RvYy9saXNwcmVmL3Ro cmVhZHMudGV4aQppbmRleCAzZDllYmYwODA3My4uYjQ1OGFkOGFlMzYgMTAwNjQ0Ci0tLSBh L2RvYy9saXNwcmVmL3RocmVhZHMudGV4aQorKysgYi9kb2MvbGlzcHJlZi90aHJlYWRzLnRl eGkKQEAgLTU1LDcgKzU1LDcgQEAgQmFzaWMgVGhyZWFkIEZ1bmN0aW9ucwogZGlyZWN0bHks IGJ1dCB0aGUgY3VycmVudCB0aHJlYWQgY2FuIGJlIGV4aXRlZCBpbXBsaWNpdGx5LCBhbmQg b3RoZXIKIHRocmVhZHMgY2FuIGJlIHNpZ25hbGVkLgogCi1AZGVmdW4gbWFrZS10aHJlYWQg ZnVuY3Rpb24gJm9wdGlvbmFsIG5hbWUKK0BkZWZ1biBtYWtlLXRocmVhZCBmdW5jdGlvbiAm b3B0aW9uYWwgbmFtZSBidWZmZXItZGlzcG9zaXRpb24KIENyZWF0ZSBhIG5ldyB0aHJlYWQg b2YgZXhlY3V0aW9uIHdoaWNoIGludm9rZXMgQHZhcntmdW5jdGlvbn0uICBXaGVuCiBAdmFy e2Z1bmN0aW9ufSByZXR1cm5zLCB0aGUgdGhyZWFkIGV4aXRzLgogCkBAIC02Niw5ICs2Niwy MiBAQCBCYXNpYyBUaHJlYWQgRnVuY3Rpb25zCiB1c2VkIGZvciBkZWJ1Z2dpbmcgYW5kIGlu Zm9ybWF0aW9uYWwgcHVycG9zZXMgb25seTsgaXQgaGFzIG5vIG1lYW5pbmcKIHRvIEVtYWNz LiAgSWYgQHZhcntuYW1lfSBpcyBwcm92aWRlZCwgaXQgbXVzdCBiZSBhIHN0cmluZy4KIAor QHZhcntidWZmZXItZGlzcG9zaXRpb259IGluZGljYXRlcyB3aGF0IGhhcHBlbnMgaWYgdGhl IHRocmVhZCdzIGN1cnJlbnQKK2J1ZmZlciBpcyBhYm91dCB0byBiZSBraWxsZWQuICBJZiB0 aGUgdmFsdWUgaXMgQGNvZGV7dH0sIGl0J3Mgbm90CithbGxvd2VkLiAgQW55IG90aGVyIHZh bHVlLCBpbmNsdWRpbmcgbmlsICh3aGljaCBpcyB0aGUgZGVmYXVsdCksIG1lYW5zCit0aGF0 IHRoZSBidWZmZXIgaXMga2lsbGVkIGFuZCB0aGUgdGhyZWFkIGlzIGFzc2lnbmVkIGFub3Ro ZXIgY3VycmVudAorYnVmZmVyLCBhbmQgaXQncyBzaWduYWxlZCB0aGUgZXJyb3IgQGNvZGV7 dGhyZWFkLWJ1ZmZlci1raWxsZWR9LiAgQnV0IGlmCit0aGUgdmFsdWUgaXMgdGhlIHN5bWJv bCBAY29kZXtzaWxlbnRseX0sIHRoZSBlcnJvciBpcyBub3Qgc2lnbmFsZWQuCisKIFRoaXMg ZnVuY3Rpb24gcmV0dXJucyB0aGUgbmV3IHRocmVhZC4KIEBlbmQgZGVmdW4KIAorQGZpbmRl eCB0aHJlYWQtYnVmZmVyLWRpc3Bvc2l0aW9uCitAZmluZGV4IHRocmVhZC1zZXQtYnVmZmVy LWRpc3Bvc2l0aW9uCitBZnRlciBhIHRocmVhZCBoYWQgYmVlbiBjcmVhdGVkLCB5b3UgY2Fu IGluc3BlY3Qgb3IgY2hhbmdlIGl0cworYnVmZmVyLWRpc3Bvc2l0aW9uIHVzaW5nIGZ1bmN0 aW9ucyBAY29kZXt0aHJlYWQtYnVmZmVyLWRpc3Bvc2l0aW9ufSBhbmQKK0Bjb2Rle3RocmVh ZC1zZXQtYnVmZmVyLWRpc3Bvc2l0aW9ufS4KKwogQGRlZnVuIHRocmVhZHAgb2JqZWN0CiBU aGlzIGZ1bmN0aW9uIHJldHVybnMgQGNvZGV7dH0gaWYgQHZhcntvYmplY3R9IHJlcHJlc2Vu dHMgYW4gRW1hY3MKIHRocmVhZCwgQGNvZGV7bmlsfSBvdGhlcndpc2UuCmRpZmYgLS1naXQg YS9zcmMvYnVmZmVyLmMgYi9zcmMvYnVmZmVyLmMKaW5kZXggYTQ2NTE1MzI3OWQuLmU0NGI2 ZGFmNTg3IDEwMDY0NAotLS0gYS9zcmMvYnVmZmVyLmMKKysrIGIvc3JjL2J1ZmZlci5jCkBA IC0yMDUwLDYgKzIwNTAsMTMgQEAgREVGVU4gKCJraWxsLWJ1ZmZlciIsIEZraWxsX2J1ZmZl ciwgU2tpbGxfYnVmZmVyLCAwLCAxLCAiYktpbGwgYnVmZmVyOiAiLAogCXJldHVybiBRbmls OwogICAgIH0KIAorICAvKiBDaGVjayBhbGwgdGhyZWFkcyBhZ2FpbiwgaW4gY2FzZSBhIGhv b2sgY2hhbmdlZCBzb21ldGhpbmcuICAqLworICBpZiAodGhyZWFkX2NoZWNrX2N1cnJlbnRf YnVmZmVyIChiKSkKKyAgICByZXR1cm4gUW5pbDsKKworICAvKiBDbGVhbiB1cCByZWZlcmVu Y2VzIHRvIHRoZSBidWZmZXIgaW4gdGhyZWFkcy4gICovCisgIHRocmVhZF9hbGxfYmVmb3Jl X2J1ZmZlcl9raWxsZWQgKGJ1ZmZlcik7CisKICAgLyogSWYgdGhlIGJ1ZmZlciBub3cgY3Vy cmVudCBpcyBzaG93biBpbiB0aGUgbWluaWJ1ZmZlciBhbmQgb3VyIGJ1ZmZlcgogICAgICBp cyB0aGUgc29sZSBvdGhlciBidWZmZXIgZ2l2ZSB1cC4gICovCiAgIFhTRVRCVUZGRVIgKHRl bSwgY3VycmVudF9idWZmZXIpOwpkaWZmIC0tZ2l0IGEvc3JjL3RocmVhZC5jIGIvc3JjL3Ro cmVhZC5jCmluZGV4IDhmZDcxM2QwYzgxLi4zZDI5ZjZjNTkxYSAxMDA2NDQKLS0tIGEvc3Jj L3RocmVhZC5jCisrKyBiL3NyYy90aHJlYWQuYwpAQCAtODgyLDExICs4ODIsMTggQEAgZmlu YWxpemVfb25lX3RocmVhZCAoc3RydWN0IHRocmVhZF9zdGF0ZSAqc3RhdGUpCiAgIGZyZWVf YmNfdGhyZWFkICgmc3RhdGUtPmJjKTsKIH0KIAotREVGVU4gKCJtYWtlLXRocmVhZCIsIEZt YWtlX3RocmVhZCwgU21ha2VfdGhyZWFkLCAxLCAyLCAwLAorREVGVU4gKCJtYWtlLXRocmVh ZCIsIEZtYWtlX3RocmVhZCwgU21ha2VfdGhyZWFkLCAxLCAzLCAwLAogICAgICAgIGRvYzog LyogU3RhcnQgYSBuZXcgdGhyZWFkIGFuZCBydW4gRlVOQ1RJT04gaW4gaXQuCiBXaGVuIHRo ZSBmdW5jdGlvbiBleGl0cywgdGhlIHRocmVhZCBkaWVzLgotSWYgTkFNRSBpcyBnaXZlbiwg aXQgbXVzdCBiZSBhIHN0cmluZzsgaXQgbmFtZXMgdGhlIG5ldyB0aHJlYWQuICAqLykKLSAg KExpc3BfT2JqZWN0IGZ1bmN0aW9uLCBMaXNwX09iamVjdCBuYW1lKQorSWYgTkFNRSBpcyBn aXZlbiwgaXQgbXVzdCBiZSBhIHN0cmluZzsgaXQgbmFtZXMgdGhlIG5ldyB0aHJlYWQuCisK K0JVRkZFUi1ESVNQT1NJVElPTiBkZXRlcm1pbmVzIGhvdyBhdHRhY2hlZCB0aGUgdGhyZWFk IGlzIHRvIGl0cyBjdXJyZW50CitidWZmZXIuICBJZiB0aGUgdmFsdWUgaXMgdCwgdGhhdCBi dWZmZXIgY2FuJ3QgYmUga2lsbGVkLiAgQW55IG90aGVyCit2YWx1ZSwgaW5jbHVkaW5nIG5p bCAodGhlIGRlZmF1bHQpLCBtZWFucyB0aGF0IGlmIGl0cyBidWZmZXIgaXMga2lsbGVkLAor dGhlIHRocmVhZCBpcyBzd2l0Y2hlZCB0byBhbm90aGVyIGJ1ZmZlciBhbmQgcmVjZWl2ZXMg YW4gZXJyb3Igc2lnbmFsCitgdGhyZWFkLWJ1ZmZlci1raWxsZWQnLiAgQnV0IGlmIHRoZSB2 YWx1ZSBpcyBzeW1ib2wgYHNpbGVudGx5Jywgbm8gZXJyb3IKK3dpbGwgYmUgc2lnbmFsZWQu ICAqLykKKyAgKExpc3BfT2JqZWN0IGZ1bmN0aW9uLCBMaXNwX09iamVjdCBuYW1lLCBMaXNw X09iamVjdCBidWZmZXJfZGlzcG9zaXRpb24pCiB7CiAgIC8qIENhbid0IHN0YXJ0IGEgdGhy ZWFkIGluIHRlbWFjcy4gICovCiAgIGlmICghaW5pdGlhbGl6ZWQpCkBAIC05MzQsNiArOTQx LDggQEAgREVGVU4gKCJtYWtlLXRocmVhZCIsIEZtYWtlX3RocmVhZCwgU21ha2VfdGhyZWFk LCAxLCAyLCAwLAogI2VuZGlmCiAgICAgfQogCisgIG5ld190aHJlYWQtPmJ1ZmZlcl9kaXNw b3NpdGlvbiA9IGJ1ZmZlcl9kaXNwb3NpdGlvbjsKKwogICAvKiBGSVhNRTogcmFjZSBoZXJl IHdoZXJlIG5ldyB0aHJlYWQgbWlnaHQgbm90IGJlIGZpbGxlZCBpbj8gICovCiAgIExpc3Bf T2JqZWN0IHJlc3VsdDsKICAgWFNFVFRIUkVBRCAocmVzdWx0LCBuZXdfdGhyZWFkKTsKQEAg LTk3Miw2ICs5ODEsMTUgQEAgdGhyZWFkX3NpZ25hbF9jYWxsYmFjayAodm9pZCAqYXJnKQog ICBwb3N0X2FjcXVpcmVfZ2xvYmFsX2xvY2sgKHNlbGYpOwogfQogCitzdGF0aWMgdm9pZAor dGhyZWFkX3NldF9lcnJvciAoc3RydWN0IHRocmVhZF9zdGF0ZSAqdHN0YXRlLCBMaXNwX09i amVjdCBlcnJvcl9zeW1ib2wsIExpc3BfT2JqZWN0IGRhdGEpCit7CisgIC8qIFdoYXQgdG8g ZG8gaWYgdGhyZWFkIGlzIGFscmVhZHkgc2lnbmFsZWQ/ICAqLworICAvKiBXaGF0IGlmIGVy cm9yX3N5bWJvbCBpcyBRbmlsPyAgKi8KKyAgdHN0YXRlLT5lcnJvcl9zeW1ib2wgPSBlcnJv cl9zeW1ib2w7CisgIHRzdGF0ZS0+ZXJyb3JfZGF0YSA9IGRhdGE7Cit9CisKIERFRlVOICgi dGhyZWFkLXNpZ25hbCIsIEZ0aHJlYWRfc2lnbmFsLCBTdGhyZWFkX3NpZ25hbCwgMywgMywg MCwKICAgICAgICBkb2M6IC8qIFNpZ25hbCBhbiBlcnJvciBpbiBhIHRocmVhZC4KIFRoaXMg YWN0cyBsaWtlIGBzaWduYWwnLCBidXQgYXJyYW5nZXMgZm9yIHRoZSBzaWduYWwgdG8gYmUg cmFpc2VkCkBAIC0xMDA2LDEwICsxMDI0LDcgQEAgREVGVU4gKCJ0aHJlYWQtc2lnbmFsIiwg RnRocmVhZF9zaWduYWwsIFN0aHJlYWRfc2lnbmFsLCAzLCAzLCAwLAogICBlbHNlCiAjZW5k aWYKICAgICB7Ci0gICAgICAvKiBXaGF0IHRvIGRvIGlmIHRocmVhZCBpcyBhbHJlYWR5IHNp Z25hbGVkPyAgKi8KLSAgICAgIC8qIFdoYXQgaWYgZXJyb3Jfc3ltYm9sIGlzIFFuaWw/ICAq LwotICAgICAgdHN0YXRlLT5lcnJvcl9zeW1ib2wgPSBlcnJvcl9zeW1ib2w7Ci0gICAgICB0 c3RhdGUtPmVycm9yX2RhdGEgPSBkYXRhOworICAgICAgdGhyZWFkX3NldF9lcnJvciAodHN0 YXRlLCBlcnJvcl9zeW1ib2wsIGRhdGEpOwogCiAgICAgICBpZiAodHN0YXRlLT53YWl0X2Nv bmR2YXIpCiAJZmx1c2hfc3RhY2tfY2FsbF9mdW5jICh0aHJlYWRfc2lnbmFsX2NhbGxiYWNr LCB0c3RhdGUpOwpAQCAtMTAzMCw2ICsxMDQ1LDQxIEBAIERFRlVOICgidGhyZWFkLWxpdmUt cCIsIEZ0aHJlYWRfbGl2ZV9wLCBTdGhyZWFkX2xpdmVfcCwgMSwgMSwgMCwKICAgcmV0dXJu IHRocmVhZF9saXZlX3AgKHRzdGF0ZSkgPyBRdCA6IFFuaWw7CiB9CiAKK0RFRlVOICgidGhy ZWFkLWJ1ZmZlci1kaXNwb3NpdGlvbiIsIEZ0aHJlYWRfYnVmZmVyX2Rpc3Bvc2l0aW9uLCBT dGhyZWFkX2J1ZmZlcl9kaXNwb3NpdGlvbiwKKyAgICAgICAxLCAxLCAwLAorICAgICAgIGRv YzogLyogUmV0dXJuIHRoZSB2YWx1ZSBvZiBUSFJFQUQncyBidWZmZXIgZGlzcG9zaXRpb24u CitTZWUgYG1ha2UtdGhyZWFkJyBmb3IgdGhlIGRlc2NyaXB0aW9uIG9mIHBvc3NpYmxlIHZh bHVlcy4gICovKQorICAoTGlzcF9PYmplY3QgdGhyZWFkKQoreworICBzdHJ1Y3QgdGhyZWFk X3N0YXRlICp0c3RhdGU7CisKKyAgQ0hFQ0tfVEhSRUFEICh0aHJlYWQpOworICB0c3RhdGUg PSBYVEhSRUFEICh0aHJlYWQpOworCisgIHJldHVybiB0c3RhdGUtPmJ1ZmZlcl9kaXNwb3Np dGlvbjsKK30KKworREVGVU4gKCJ0aHJlYWQtc2V0LWJ1ZmZlci1kaXNwb3NpdGlvbiIsIEZ0 aHJlYWRfc2V0X2J1ZmZlcl9kaXNwb3NpdGlvbiwgU3RocmVhZF9zZXRfYnVmZmVyX2Rpc3Bv c2l0aW9uLAorICAgICAgIDIsIDIsIDAsCisgICAgICAgZG9jOiAvKiBTZXQgVEhSRUFEJ3Mg YnVmZmVyIGRpc3Bvc2l0aW9uLgorU2VlIGBtYWtlLXRocmVhZCcgZm9yIHRoZSBkZXNjcmlw dGlvbiBvZiBwb3NzaWJsZSB2YWx1ZXMuCisKK0J1ZmZlciBkaXNwb3NpdGlvbiBvZiB0aGUg bWFpbiB0aHJlYWQgY2Fubm90IGJlIG1vZGlmaWVkLiAgKi8pCisgIChMaXNwX09iamVjdCB0 aHJlYWQsIExpc3BfT2JqZWN0IHZhbHVlKQoreworICBzdHJ1Y3QgdGhyZWFkX3N0YXRlICp0 c3RhdGU7CisKKyAgQ0hFQ0tfVEhSRUFEICh0aHJlYWQpOworICB0c3RhdGUgPSBYVEhSRUFE ICh0aHJlYWQpOworCisgIGlmIChtYWluX3RocmVhZF9wICh0c3RhdGUpKQorICAgIENIRUNL X1RZUEUgKE5JTFAgKHZhbHVlKSwgUW51bGwsIHZhbHVlKTsKKworICB0c3RhdGUtPmJ1ZmZl cl9kaXNwb3NpdGlvbiA9IHZhbHVlOworCisgIHJldHVybiB2YWx1ZTsKK30KKwogREVGVU4g KCJ0aHJlYWQtLWJsb2NrZXIiLCBGdGhyZWFkX2Jsb2NrZXIsIFN0aHJlYWRfYmxvY2tlciwg MSwgMSwgMCwKICAgICAgICBkb2M6IC8qIFJldHVybiB0aGUgb2JqZWN0IHRoYXQgVEhSRUFE IGlzIGJsb2NraW5nIG9uLgogSWYgVEhSRUFEIGlzIGJsb2NrZWQgaW4gYHRocmVhZC1qb2lu JyBvbiBhIHNlY29uZCB0aHJlYWQsIHJldHVybiB0aGF0CkBAIC0xMTM5LDEzICsxMTg5LDQz IEBAIHRocmVhZF9jaGVja19jdXJyZW50X2J1ZmZlciAoc3RydWN0IGJ1ZmZlciAqYnVmZmVy KQogICAgICAgaWYgKGl0ZXIgPT0gY3VycmVudF90aHJlYWQpCiAJY29udGludWU7CiAKLSAg ICAgIGlmIChpdGVyLT5tX2N1cnJlbnRfYnVmZmVyID09IGJ1ZmZlcikKKyAgICAgIGlmIChp dGVyLT5tX2N1cnJlbnRfYnVmZmVyID09IGJ1ZmZlciAmJiBFUSAoaXRlci0+YnVmZmVyX2Rp c3Bvc2l0aW9uLCBRdCkpCiAJcmV0dXJuIHRydWU7CiAgICAgfQogCiAgIHJldHVybiBmYWxz ZTsKIH0KIAordm9pZAordGhyZWFkX2FsbF9iZWZvcmVfYnVmZmVyX2tpbGxlZCAoTGlzcF9P YmplY3QgY3VycmVudCkKK3sKKyAgc3RydWN0IHRocmVhZF9zdGF0ZSAqaXRlcjsKKyAgc3Ry dWN0IGJ1ZmZlciAqIG90aGVyID0gTlVMTDsKKyAgc3RydWN0IGJ1ZmZlciAqIGIgPSBYQlVG RkVSIChjdXJyZW50KTsKKyAgc3RydWN0IHRocmVhZF9zdGF0ZSAqY2FsbGVyX3RocmVhZCA9 IGN1cnJlbnRfdGhyZWFkOworCisgIGZvciAoaXRlciA9IGFsbF90aHJlYWRzOyBpdGVyOyBp dGVyID0gaXRlci0+bmV4dF90aHJlYWQpCisgICAgeworICAgICAgaWYgKGl0ZXIgPT0gY2Fs bGVyX3RocmVhZCkKKwljb250aW51ZTsKKworICAgICAgaWYgKGl0ZXItPm1fY3VycmVudF9i dWZmZXIgPT0gYikKKwl7CisJICBMaXNwX09iamVjdCB0aHJlYWQ7CisKKwkgIFhTRVRUSFJF QUQgKHRocmVhZCwgaXRlcik7CisKKwkgIGlmIChvdGhlciA9PSBOVUxMKQorCSAgICBvdGhl ciA9IFhCVUZGRVIgKEZvdGhlcl9idWZmZXIgKGN1cnJlbnQsIFFuaWwsIFFuaWwpKTsKKwor CSAgaWYgKCFFUSAoaXRlci0+YnVmZmVyX2Rpc3Bvc2l0aW9uLCBRc2lsZW50bHkpKQorCSAg ICB0aHJlYWRfc2V0X2Vycm9yIChpdGVyLCBRdGhyZWFkX2J1ZmZlcl9raWxsZWQsIFFuaWwp OworCisJICBpdGVyLT5tX2N1cnJlbnRfYnVmZmVyID0gb3RoZXI7CisJfQorICAgIH0KK30K KwogDAogCiBib29sCkBAIC0xMTc0LDYgKzEyNTQsNyBAQCBpbml0X3RocmVhZHMgKHZvaWQp CiAjZW5kaWYgLyogZGVmaW5lZCBIQVZFX0FORFJPSUQgJiYgIWRlZmluZWQgQU5EUk9JRF9T VFVCSUZZICovCiAKICAgbWFpbl90aHJlYWQucy50aHJlYWRfaWQgPSBzeXNfdGhyZWFkX3Nl bGYgKCk7CisgIG1haW5fdGhyZWFkLnMuYnVmZmVyX2Rpc3Bvc2l0aW9uID0gUW5pbDsKICAg aW5pdF9iY190aHJlYWQgKCZtYWluX3RocmVhZC5zLmJjKTsKIH0KIApAQCAtMTIwMyw2ICsx Mjg0LDggQEAgc3ltc19vZl90aHJlYWRzICh2b2lkKQogICAgICAgZGVmc3ViciAoJlNjb25k aXRpb25fbXV0ZXgpOwogICAgICAgZGVmc3ViciAoJlNjb25kaXRpb25fbmFtZSk7CiAgICAg ICBkZWZzdWJyICgmU3RocmVhZF9sYXN0X2Vycm9yKTsKKyAgICAgIGRlZnN1YnIgKCZTdGhy ZWFkX2J1ZmZlcl9kaXNwb3NpdGlvbik7CisgICAgICBkZWZzdWJyICgmU3RocmVhZF9zZXRf YnVmZmVyX2Rpc3Bvc2l0aW9uKTsKIAogICAgICAgc3RhdGljcHJvICgmbGFzdF90aHJlYWRf ZXJyb3IpOwogICAgICAgbGFzdF90aHJlYWRfZXJyb3IgPSBRbmlsOwpAQCAtMTIxNCw2ICsx Mjk3LDEzIEBAIHN5bXNfb2ZfdGhyZWFkcyAodm9pZCkKICAgREVGU1lNIChRbXV0ZXhwLCAi bXV0ZXhwIik7CiAgIERFRlNZTSAoUWNvbmRpdGlvbl92YXJpYWJsZV9wLCAiY29uZGl0aW9u LXZhcmlhYmxlLXAiKTsKIAorICBERUZTWU0gKFF0aHJlYWRfYnVmZmVyX2tpbGxlZCwgInRo cmVhZC1idWZmZXIta2lsbGVkIik7CisgIEZwdXQgKFF0aHJlYWRfYnVmZmVyX2tpbGxlZCwg UWVycm9yX2NvbmRpdGlvbnMsCisJbGlzdCAoUXRocmVhZF9idWZmZXJfa2lsbGVkLCBRZXJy b3IpKTsKKyAgRnB1dCAoUXRocmVhZF9idWZmZXJfa2lsbGVkLCBRZXJyb3JfbWVzc2FnZSwK KwlidWlsZF9zdHJpbmcgKCJUaHJlYWQncyBjdXJyZW50IGJ1ZmZlciBraWxsZWQiKSk7Cisg IERFRlNZTSAoUXNpbGVudGx5LCAic2lsZW50bHkiKTsKKwogICBERUZWQVJfTElTUCAoIm1h aW4tdGhyZWFkIiwgVm1haW5fdGhyZWFkLAogICAgIGRvYzogLyogVGhlIG1haW4gdGhyZWFk IG9mIEVtYWNzLiAgKi8pOwogI2lmZGVmIFRIUkVBRFNfRU5BQkxFRApkaWZmIC0tZ2l0IGEv c3JjL3RocmVhZC5oIGIvc3JjL3RocmVhZC5oCmluZGV4IGM0OTY0NTNiMDkwLi4zMjBhM2Uz MWRmNCAxMDA2NDQKLS0tIGEvc3JjL3RocmVhZC5oCisrKyBiL3NyYy90aHJlYWQuaApAQCAt MTQzLDYgKzE0Myw5IEBAICNkZWZpbmUgbGlzcF9ldmFsX2RlcHRoIChjdXJyZW50X3RocmVh ZC0+bV9saXNwX2V2YWxfZGVwdGgpCiAgIHN0cnVjdCBidWZmZXIgKm1fY3VycmVudF9idWZm ZXI7CiAjZGVmaW5lIGN1cnJlbnRfYnVmZmVyIChjdXJyZW50X3RocmVhZC0+bV9jdXJyZW50 X2J1ZmZlcikKIAorICAvKiBEZWNpZGVzIHdoZXRoZXIgdGhlIHRocmVhZCdzIGN1cnJlbnQg YnVmZmVyIGNhbiBiZSBraWxsZWQuICAqLworICBMaXNwX09iamVjdCBidWZmZXJfZGlzcG9z aXRpb247CisKICAgLyogRXZlcnkgY2FsbCB0byByZV9zZWFyY2gsIGV0Yy4sIG11c3QgcGFz cyAmc2VhcmNoX3JlZ3MgYXMgdGhlIHJlZ3MKICAgICAgYXJndW1lbnQgdW5sZXNzIHlvdSBj YW4gc2hvdyBpdCBpcyB1bm5lY2Vzc2FyeSAoaS5lLiwgaWYgcmVfc2VhcmNoCiAgICAgIGlz IGNlcnRhaW5seSBnb2luZyB0byBiZSBjYWxsZWQgYWdhaW4gYmVmb3JlIHJlZ2lvbi1hcm91 bmQtbWF0Y2gKQEAgLTMzOCw2ICszNDEsOCBAQCBYQ09ORFZBUiAoTGlzcF9PYmplY3QgYSkK IAogYm9vbCB0aHJlYWRfY2hlY2tfY3VycmVudF9idWZmZXIgKHN0cnVjdCBidWZmZXIgKik7 CiAKK3ZvaWQgdGhyZWFkX2FsbF9iZWZvcmVfYnVmZmVyX2tpbGxlZCAoTGlzcF9PYmplY3Qg YnVmZmVyKTsKKwogSU5MSU5FX0hFQURFUl9FTkQKIAogI2VuZGlmIC8qIFRIUkVBRF9IICov CmRpZmYgLS1naXQgYS90ZXN0L3NyYy90aHJlYWQtdGVzdHMuZWwgYi90ZXN0L3NyYy90aHJl YWQtdGVzdHMuZWwKaW5kZXggOWEwNjUxODdiNWUuLjBiOWU4Zjk2YzA5IDEwMDY0NAotLS0g YS90ZXN0L3NyYy90aHJlYWQtdGVzdHMuZWwKKysrIGIvdGVzdC9zcmMvdGhyZWFkLXRlc3Rz LmVsCkBAIC0zOTgsNiArMzk4LDcwIEBAIHRocmVhZHMtdGVzdC1idWczMzA3MwogICAobGV0 ICgodGggKG1ha2UtdGhyZWFkICdpZ25vcmUpKSkKICAgICAoc2hvdWxkLW5vdCAoZXF1YWwg dGggbWFpbi10aHJlYWQpKSkpCiAKKyhlcnQtZGVmdGVzdCB0aHJlYWQtYnVmZmVyLWRpc3Bv c2l0aW9uLXQgKCkKKyAgIlRlc3Qgbm90IGJlaW5nIGFibGUgdG8ga2lsbCBhIGJnIHRocmVh ZCdzIGJ1ZmZlci4iCisgIChza2lwLXVubGVzcyAoZmVhdHVyZXAgJ3RocmVhZHMpKQorICAo bGV0ICgoYnVmIChnZXQtYnVmZmVyLWNyZWF0ZSAiICp0aHJlYWQtYnVmZmVyLWtpbGxhYmxl LW5pbCoiKSkKKyAgICAgICAgdGhyZWFkKQorICAgICh3aXRoLWN1cnJlbnQtYnVmZmVyIGJ1 ZgorICAgICAgKHNldHEgdGhyZWFkCisgICAgICAgICAgICAobWFrZS10aHJlYWQKKyAgICAg ICAgICAgICAobGFtYmRhICgpCisgICAgICAgICAgICAgICAoc2xlZXAtZm9yIDAuMSkpCisg ICAgICAgICAgICAgbmlsCisgICAgICAgICAgICAgdCkpKQorICAgIChraWxsLWJ1ZmZlciBi dWYpCisgICAgKHNob3VsZCAoYnVmZmVyLWxpdmUtcCBidWYpKQorICAgIDs7IE5vIGVycm9y OgorICAgICh0aHJlYWQtam9pbiB0aHJlYWQpKSkKKworKGVydC1kZWZ0ZXN0IHRocmVhZC1i dWZmZXItZGlzcG9zaXRpb24tbmlsICgpCisgICJUZXN0IGtpbGxpbmcgYSBiZyB0aHJlYWQn cyBidWZmZXIuIgorICAoc2tpcC11bmxlc3MgKGZlYXR1cmVwICd0aHJlYWRzKSkKKyAgKGxl dCAoKGJ1ZiAoZ2V0LWJ1ZmZlci1jcmVhdGUgIiAqdGhyZWFkLWJ1ZmZlci1raWxsYWJsZS10 KiIpKQorICAgICAgICB0aHJlYWQpCisgICAgKHdpdGgtY3VycmVudC1idWZmZXIgYnVmCisg ICAgICAoc2V0cSB0aHJlYWQKKyAgICAgICAgICAgIChtYWtlLXRocmVhZAorICAgICAgICAg ICAgIChsYW1iZGEgKCkKKyAgICAgICAgICAgICAgIChzbGVlcC1mb3IgMC4xKSkpKSkKKyAg ICAoa2lsbC1idWZmZXIgYnVmKQorICAgIChzaG91bGQtbm90IChidWZmZXItbGl2ZS1wIGJ1 ZikpCisgICAgKHNob3VsZC1lcnJvcgorICAgICAodGhyZWFkLWpvaW4gdGhyZWFkKQorICAg ICA6dHlwZSAndGhyZWFkLWJ1ZmZlci1raWxsZWQpKSkKKworKGVydC1kZWZ0ZXN0IHRocmVh ZC1idWZmZXItZGlzcG9zaXRpb24tc2lsZW50bHkgKCkKKyAgIlRlc3Qga2lsbGluZyBhIGJn IHRocmVhZCdzIGJ1ZmZlciBzaWxlbnRseS4iCisgIChza2lwLXVubGVzcyAoZmVhdHVyZXAg J3RocmVhZHMpKQorICAobGV0ICgoYnVmIChnZXQtYnVmZmVyLWNyZWF0ZSAiICp0aHJlYWQt YnVmZmVyLWtpbGxhYmxlLXQqIikpCisgICAgICAgIHRocmVhZCkKKyAgICAod2l0aC1jdXJy ZW50LWJ1ZmZlciBidWYKKyAgICAgIChzZXRxIHRocmVhZAorICAgICAgICAgICAgKG1ha2Ut dGhyZWFkCisgICAgICAgICAgICAgKGxhbWJkYSAoKQorICAgICAgICAgICAgICAgKHNsZWVw LWZvciAwLjEpKQorICAgICAgICAgICAgIG5pbAorICAgICAgICAgICAgICdzaWxlbnRseSkp KQorICAgIChraWxsLWJ1ZmZlciBidWYpCisgICAgKHNob3VsZC1ub3QgKGJ1ZmZlci1saXZl LXAgYnVmKSkKKyAgICAodGhyZWFkLWpvaW4gdGhyZWFkKSkpCisKKyhlcnQtZGVmdGVzdCB0 aHJlYWQtc2V0LWJ1ZmZlci1kaXNwb3NpdGlvbiAoKQorICAiVGVzdCBiZWluZyBhYmxlIHRv IG1vZGlmeSBhIHRocmVhZCdzIGJ1ZmZlciBkaXNwb3NpdGlvbi4iCisgIChza2lwLXVubGVz cyAoZmVhdHVyZXAgJ3RocmVhZHMpKQorICAobGV0ICgodGhyZWFkIChtYWtlLXRocmVhZCAj J2lnbm9yZSkpKQorICAgIChzaG91bGQgKGVxICh0aHJlYWQtYnVmZmVyLWRpc3Bvc2l0aW9u IHRocmVhZCkgbmlsKSkKKyAgICAodGhyZWFkLXNldC1idWZmZXItZGlzcG9zaXRpb24gdGhy ZWFkIHQpCisgICAgKHNob3VsZCAoZXEgKHRocmVhZC1idWZmZXItZGlzcG9zaXRpb24gdGhy ZWFkKSB0KSkpKQorCisoZXJ0LWRlZnRlc3QgdGhyZWFkLXNldC1idWZmZXItZGlzcG9zaXRp b24tbWFpbi10aHJlYWQgKCkKKyAgIlRlc3Qgbm90IGJlaW5nIGFibGUgdG8gbW9kaWZ5IG1h aW4gdGhyZWFkJ3MgYnVmZmVyIGRpc3Bvc2l0aW9uLiIKKyAgKHNraXAtdW5sZXNzIChmZWF0 dXJlcCAndGhyZWFkcykpCisgIChzaG91bGQgKG51bGwgKHRocmVhZC1idWZmZXItZGlzcG9z aXRpb24gbWFpbi10aHJlYWQpKSkKKyAgKHNob3VsZC1lcnJvciAodGhyZWFkLXNldC1idWZm ZXItZGlzcG9zaXRpb24gbWFpbi10aHJlYWQgdCkKKyAgICAgICAgICAgICAgICA6dHlwZSAn d3JvbmctdHlwZS1hcmd1bWVudCkpCisKIChkZWZ2YXIgdGhyZWFkcy10ZXN0LS12YXIgJ2ds b2JhbCkKIAogKGVydC1kZWZ0ZXN0IHRocmVhZHMtdGVzdC1idWc0ODk5MCAoKQo= --------------FLfbPOEvoTN10SUTseMFBdhv-- From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 09 08:20:32 2025 Received: (at 76969) by debbugs.gnu.org; 9 Aug 2025 12:20:32 +0000 Received: from localhost ([127.0.0.1]:40610 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ukiYq-00029z-08 for submit@debbugs.gnu.org; Sat, 09 Aug 2025 08:20:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37732) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ukiYn-00029m-8X for 76969@debbugs.gnu.org; Sat, 09 Aug 2025 08:20:30 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ukiYh-00038O-Dp; Sat, 09 Aug 2025 08:20:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=q/ShRMQeNnGSzliexij4KDar/Pwk33s0W2wfhnR39ZE=; b=Kn1WhVTCUCJv 5oIaqo+h173tmIj00vtCgyGWmHRXa8U8Q7bU7XRsgLgfVcwQwILptlq+jhSbbzXSkDuL2l4WB5vJ5 t78Or/S6Mb3eLucox1Pp8OLxPZIHgHXAow384zDnKTHoNmGKUItSUQ5ZCN5+umky9cAT90VJxaAJd ixyUMXt9a8fkhsSSNVBqe8QLqDxstoocdi7liGqIXZSrv220dnHtiPJh594zKG3Yv2dz+Bc1B5n81 XVl8ajpvkd+eqyVE10xM9rQkPGLsNKHOzXomIAqeVyqbOlAa2csDUfTqWeYzWFGyOw3CTRdc9nEOa bKX9ZxsKZVb0md0TlIBNEA==; Date: Sat, 09 Aug 2025 15:20:19 +0300 Message-Id: <86wm7clm9o.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <6b1ece75-663f-4855-ae1a-de7ee15a8103@gutov.dev> (message from Dmitry Gutov on Fri, 1 Aug 2025 03:01:11 +0300) Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current References: <86bju41xoc.fsf@gnu.org> <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> <86y0x3qwbk.fsf@gnu.org> <7754f678-6c8e-4045-8c3d-e2b39680f023@gutov.dev> <54677c11-0274-443c-b2b1-079d73e34d10@gutov.dev> <86wm87gwpi.fsf@gnu.org> <9222ba4e-9a3b-4137-ae31-6796c1838d3c@gutov.dev> <86pldyf23h.fsf@gnu.org> <4a54a7ec-1d38-4d8b-be7f-e7e0ea55d94f@gutov.dev> <86ikjk9yio.fsf@gnu.org> <485bb371-7452-4ff4-9727-2397f7cc6993@gutov.dev> <86o6tb6svf.fsf@gnu.org> <867bzv1d1a.fsf@gnu.org> <86cy9hue45.fsf@gnu.org> <6b1ece75-663f-4855-ae1a-de7ee15a8103@gutov.dev> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 1 Aug 2025 03:01:11 +0300 > Cc: sbaugh@janestreet.com, 76969@debbugs.gnu.org > From: Dmitry Gutov > > +@var{buffer-disposition} indicates what happens if the thread's current > +buffer is about to be killed. If the value is @code{t}, it's not > +allowed. I'd say "killing the buffer is not allowed", because "it" might be ambiguous. > Any other value, including nil (which is the default), means ^^^ @code{nil} > --- a/src/thread.h > +++ b/src/thread.h > @@ -143,6 +143,9 @@ #define lisp_eval_depth (current_thread->m_lisp_eval_depth) > struct buffer *m_current_buffer; > #define current_buffer (current_thread->m_current_buffer) > > + /* Decides whether the thread's current buffer can be killed. */ > + Lisp_Object buffer_disposition; I think this change means ABI_VERSION in comp.c should be bumped. Also, please move this member to before event_object, because the comment there says: /* event_object must be the last Lisp field. */ which is consistent with how we allocate thread objects: struct thread_state *new_thread = ALLOCATE_ZEROED_PSEUDOVECTOR (struct thread_state, event_object, PVEC_THREAD); Finally, this needs a NEWS entry. With the above nits fixed, please feel free to install, and thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 09 16:12:05 2025 Received: (at 76969-done) by debbugs.gnu.org; 9 Aug 2025 20:12:05 +0000 Received: from localhost ([127.0.0.1]:43094 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ukpvA-0008DP-DY for submit@debbugs.gnu.org; Sat, 09 Aug 2025 16:12:05 -0400 Received: from fout-b3-smtp.messagingengine.com ([202.12.124.146]:38039) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ukpv7-0008Cn-9P for 76969-done@debbugs.gnu.org; Sat, 09 Aug 2025 16:12:03 -0400 Received: from phl-compute-09.internal (phl-compute-09.internal [10.202.2.49]) by mailfout.stl.internal (Postfix) with ESMTP id 8046E1D000D9; Sat, 9 Aug 2025 16:11:55 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-09.internal (MEProxy); Sat, 09 Aug 2025 16:11:55 -0400 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=1754770315; x=1754856715; bh=Ybcs5I1S8qY8PW2lX/XoNJ5QewoQRhZTyo4mRKkYxyo=; b= H/PZ0JXIQTyCP5bTttfx5+ewgQo8Fw97CK+605x2WvsG/K/3nheAr3uDScQQc3fJ LdEp3ee3cA9BFHffiIFOYhxN08JTVr24UdKCxNQIuZ2Duu0QAMVTEscQedaT8dcw mHRRxEwbedxWRpQ84cIhpw+5XL4jJnLRc0obMEkAP6xHSZ16guEU580OoPI9k621 JHlbQN+/KK8XQt7WWHBEqACVbE6W1WZYWtVSyPeKBxs7Au3IDd3huCxtoSgvqQ4G xF3w6zYDLDuBZH83rEzIfVlqeBBas/WrHGpMaRrEh8VmMn00TU7LEzWAaH6yYjBJ gmE5D3EhI1AMigbWIFdLGg== 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=1754770315; x= 1754856715; bh=Ybcs5I1S8qY8PW2lX/XoNJ5QewoQRhZTyo4mRKkYxyo=; b=a 0kiuqKYZ6l1v213XHB38MBGz8jDEWtA/6L1SmXLvBvcrmmwKLRJ4ept7mWf9/dzQ 2TRYH8Xp5PXeu1hMLlzxqDfTjO/WzRsPoGjb8iidUcOfIAtEDAzVJfL79VDQia1v YZcGGtgf7UHKhyTXcSH9b9KHU7EX4YbMS1nwJytRgODNGEkgvEHsgbpwG/M7CKRQ w8N3CyLbtJFX5rQfFqyB6GeI/47qkIrjnsfg2kGaZZA/IwdQAfgbvLmMTHVsun7T 2UTa790JDQ3nEUR2LUm24NJNvDLMND3WAkVcZ+xkR6vFaAFHJ0Go5j9yzYhoXkTu B9acWOOcTFLBC1OJCBU9A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdduvdejiedvucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhr hicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvg hrnhepffeifedvleeukedtgfelieegudfgveekfeejveejffetffeuueeugefhveeiuddv necuffhomhgrihhnpehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgt phhtthhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuh drohhrghdprhgtphhtthhopehssggruhhghhesjhgrnhgvshhtrhgvvghtrdgtohhmpdhr tghpthhtohepjeeileeiledqughonhgvseguvggssghughhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 9 Aug 2025 16:11:53 -0400 (EDT) Message-ID: <50a5a35b-c229-4c1f-b86d-a321676f4bb4@gutov.dev> Date: Sat, 9 Aug 2025 23:11:51 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current To: Eli Zaretskii References: <72d70cd7-5532-4139-a495-c8c8899820ae@gutov.dev> <86zfhoysxg.fsf@gnu.org> <8e5d1340-9d4f-4892-b941-63de9f21f86f@gutov.dev> <86o6y2y72g.fsf@gnu.org> <868qp6wfq0.fsf@gnu.org> <80171522-07e5-4acb-a85b-d12825678097@gutov.dev> <86ldt5v78p.fsf@gnu.org> <86y0x3qwbk.fsf@gnu.org> <7754f678-6c8e-4045-8c3d-e2b39680f023@gutov.dev> <54677c11-0274-443c-b2b1-079d73e34d10@gutov.dev> <86wm87gwpi.fsf@gnu.org> <9222ba4e-9a3b-4137-ae31-6796c1838d3c@gutov.dev> <86pldyf23h.fsf@gnu.org> <4a54a7ec-1d38-4d8b-be7f-e7e0ea55d94f@gutov.dev> <86ikjk9yio.fsf@gnu.org> <485bb371-7452-4ff4-9727-2397f7cc6993@gutov.dev> <86o6tb6svf.fsf@gnu.org> <867bzv1d1a.fsf@gnu.org> <86cy9hue45.fsf@gnu.org> <6b1ece75-663f-4855-ae1a-de7ee15a8103@gutov.dev> <86wm7clm9o.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86wm7clm9o.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 76969-done Cc: sbaugh@janestreet.com, 76969-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 09/08/2025 15:20, Eli Zaretskii wrote: >> Date: Fri, 1 Aug 2025 03:01:11 +0300 >> Cc:sbaugh@janestreet.com,76969@debbugs.gnu.org >> From: Dmitry Gutov >> >> +@var{buffer-disposition} indicates what happens if the thread's current >> +buffer is about to be killed. If the value is @code{t}, it's not >> +allowed. > I'd say "killing the buffer is not allowed", because "it" might be > ambiguous. > >> Any other value, including nil (which is the default), means > ^^^ > @code{nil} > >> --- a/src/thread.h >> +++ b/src/thread.h >> @@ -143,6 +143,9 @@ #define lisp_eval_depth (current_thread->m_lisp_eval_depth) >> struct buffer *m_current_buffer; >> #define current_buffer (current_thread->m_current_buffer) >> >> + /* Decides whether the thread's current buffer can be killed. */ >> + Lisp_Object buffer_disposition; > I think this change means ABI_VERSION in comp.c should be bumped. > > Also, please move this member to before event_object, because the > comment there says: > > /* event_object must be the last Lisp field. */ > > which is consistent with how we allocate thread objects: > > struct thread_state *new_thread > = ALLOCATE_ZEROED_PSEUDOVECTOR (struct thread_state, event_object, > PVEC_THREAD); > > Finally, this needs a NEWS entry. > > With the above nits fixed, please feel free to install, and thanks. Thanks! Done all that and pushed to master: https://cgit.git.savannah.gnu.org/cgit/emacs.git/commit/?id=07eb39f1132ceb15e80e7912445890faa8f5b78c Now closing, and let's be on lookout for user feedback.