Received: (at 76969) by debbugs.gnu.org; 17 Mar 2025 19:41:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 17 15:41:32 2025 Received: from localhost ([127.0.0.1]:32803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tuGL6-0000Ey-8H for submit <at> 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 <eliz@HIDDEN>) id 1tuGL2-0000Dt-U2 for 76969 <at> 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 <eliz@HIDDEN>) 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@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <iersenbqxfu.fsf@HIDDEN> (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: <b8987709-43ea-47ed-8172-31a037e29d78@HIDDEN> <86senh2ren.fsf@HIDDEN> <15badabb-b95d-4c32-b5d5-4b98fa8db528@HIDDEN> <86wmct0yfj.fsf@HIDDEN> <a9e65d85-8887-4ed0-8ff2-302b0e1ca954@HIDDEN> <86bju41xoc.fsf@HIDDEN> <72d70cd7-5532-4139-a495-c8c8899820ae@HIDDEN> <86zfhoysxg.fsf@HIDDEN> <8e5d1340-9d4f-4892-b941-63de9f21f86f@HIDDEN> <86o6y2y72g.fsf@HIDDEN> <fdde0569-2d95-4933-9792-82b7fc6bb63e@HIDDEN> <868qp6wfq0.fsf@HIDDEN> <80171522-07e5-4acb-a85b-d12825678097@HIDDEN> <86ldt5v78p.fsf@HIDDEN> <iersenbqxfu.fsf@HIDDEN> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 76969 Cc: dmitry@HIDDEN, 76969 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.6 (--) > From: Spencer Baugh <sbaugh@HIDDEN> > Cc: Dmitry Gutov <dmitry@HIDDEN>, 76969 <at> debbugs.gnu.org > Date: Mon, 17 Mar 2025 15:17:09 -0400 > > Eli Zaretskii <eliz@HIDDEN> writes: > >> Date: Sun, 16 Mar 2025 01:29:00 +0200 > >> Cc: 76969 <at> debbugs.gnu.org, sbaugh@HIDDEN > >> From: Dmitry Gutov <dmitry@HIDDEN> > >> > >> 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.
bug-gnu-emacs@HIDDEN:bug#76969; Package emacs.
Full text available.Received: (at 76969) by debbugs.gnu.org; 17 Mar 2025 19:17:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 17 15:17:18 2025 Received: from localhost ([127.0.0.1]:60969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tuFxe-0005iL-Ap for submit <at> 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 <sbaugh@HIDDEN>) id 1tuFxb-0005ej-Js for 76969 <at> debbugs.gnu.org; Mon, 17 Mar 2025 15:17:16 -0400 From: Spencer Baugh <sbaugh@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current In-Reply-To: <86ldt5v78p.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 16 Mar 2025 08:07:18 +0200") References: <b8987709-43ea-47ed-8172-31a037e29d78@HIDDEN> <86senh2ren.fsf@HIDDEN> <15badabb-b95d-4c32-b5d5-4b98fa8db528@HIDDEN> <86wmct0yfj.fsf@HIDDEN> <a9e65d85-8887-4ed0-8ff2-302b0e1ca954@HIDDEN> <86bju41xoc.fsf@HIDDEN> <72d70cd7-5532-4139-a495-c8c8899820ae@HIDDEN> <86zfhoysxg.fsf@HIDDEN> <8e5d1340-9d4f-4892-b941-63de9f21f86f@HIDDEN> <86o6y2y72g.fsf@HIDDEN> <fdde0569-2d95-4933-9792-82b7fc6bb63e@HIDDEN> <868qp6wfq0.fsf@HIDDEN> <80171522-07e5-4acb-a85b-d12825678097@HIDDEN> <86ldt5v78p.fsf@HIDDEN> Date: Mon, 17 Mar 2025 15:17:09 -0400 Message-ID: <iersenbqxfu.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=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 <dmitry@HIDDEN>, 76969 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.6 (--) Eli Zaretskii <eliz@HIDDEN> writes: >> Date: Sun, 16 Mar 2025 01:29:00 +0200 >> Cc: 76969 <at> debbugs.gnu.org, sbaugh@HIDDEN >> From: Dmitry Gutov <dmitry@HIDDEN> >> >> 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.
bug-gnu-emacs@HIDDEN:bug#76969; Package emacs.
Full text available.Received: (at 76969) by debbugs.gnu.org; 16 Mar 2025 06:07:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 16 02:07:36 2025 Received: from localhost ([127.0.0.1]:44973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tth9r-0000p8-FF for submit <at> 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 <eliz@HIDDEN>) id 1tth9o-0000no-Sj for 76969 <at> 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 <eliz@HIDDEN>) 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@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <80171522-07e5-4acb-a85b-d12825678097@HIDDEN> (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: <b8987709-43ea-47ed-8172-31a037e29d78@HIDDEN> <86senh2ren.fsf@HIDDEN> <15badabb-b95d-4c32-b5d5-4b98fa8db528@HIDDEN> <86wmct0yfj.fsf@HIDDEN> <a9e65d85-8887-4ed0-8ff2-302b0e1ca954@HIDDEN> <86bju41xoc.fsf@HIDDEN> <72d70cd7-5532-4139-a495-c8c8899820ae@HIDDEN> <86zfhoysxg.fsf@HIDDEN> <8e5d1340-9d4f-4892-b941-63de9f21f86f@HIDDEN> <86o6y2y72g.fsf@HIDDEN> <fdde0569-2d95-4933-9792-82b7fc6bb63e@HIDDEN> <868qp6wfq0.fsf@HIDDEN> <80171522-07e5-4acb-a85b-d12825678097@HIDDEN> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@HIDDEN, 76969 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.6 (--) > Date: Sun, 16 Mar 2025 01:29:00 +0200 > Cc: 76969 <at> debbugs.gnu.org, sbaugh@HIDDEN > From: Dmitry Gutov <dmitry@HIDDEN> > > 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.
bug-gnu-emacs@HIDDEN:bug#76969; Package emacs.
Full text available.Received: (at 76969) by debbugs.gnu.org; 15 Mar 2025 23:29:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 15 19:29:16 2025 Received: from localhost ([127.0.0.1]:43997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ttawN-0000Ca-Fx for submit <at> 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 <dmitry@HIDDEN>) id 1ttawI-0000Bz-Fd for 76969 <at> 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: <xms:QA3WZx8tdl9G7ow4o72KqcK3Q5-gjhD1wSkO6W-keI9TjeH7an1tcw> <xme:QA3WZ1ssZZSOojlwAqxG4dCrUsF9NLYJIOl6M5x1J2stknqPJFgZmlG6ZMJun89ap -EaeVAY0V7snJ53_yo> X-ME-Received: <xmr:QA3WZ_D8Mdq_IdNyiA3-KRuBA9hkpk50Cq6hfaeFZVFjHcXfHRfGUYwJj1etrOpoqr3v> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddufeehtdegucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddt vdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovh druggvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieek ueeftddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphht thhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdroh hrghdprhgtphhtthhopeejieelieelseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp thhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomh X-ME-Proxy: <xmx:QA3WZ1e-q2KBFDDJv0Pmvl15qVS9njOgZQtyMAhplguxGmOjlIfySA> <xmx:QA3WZ2P5mXasrqlW-5jL7fswzzV91ldjd9fsZCQ_B5H24HxQBwy61A> <xmx:QA3WZ3m9yBdKRbYSqoPHyDcfkTKYnFvKuxnK9Y5QBHdqNA_mZZpShA> <xmx:QA3WZwv03IahFO5traXMckbk9hjlVJqQ_LqdpFpF8XtgEyTQnxIg0w> <xmx:QA3WZzr5sy2N7rHlrRYYcvk0rVfFADEyehwloON2BZrU_vGsN1qEjDsW> 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@HIDDEN> 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 <eliz@HIDDEN> References: <b8987709-43ea-47ed-8172-31a037e29d78@HIDDEN> <86senh2ren.fsf@HIDDEN> <15badabb-b95d-4c32-b5d5-4b98fa8db528@HIDDEN> <86wmct0yfj.fsf@HIDDEN> <a9e65d85-8887-4ed0-8ff2-302b0e1ca954@HIDDEN> <86bju41xoc.fsf@HIDDEN> <72d70cd7-5532-4139-a495-c8c8899820ae@HIDDEN> <86zfhoysxg.fsf@HIDDEN> <8e5d1340-9d4f-4892-b941-63de9f21f86f@HIDDEN> <86o6y2y72g.fsf@HIDDEN> <fdde0569-2d95-4933-9792-82b7fc6bb63e@HIDDEN> <868qp6wfq0.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <868qp6wfq0.fsf@HIDDEN> 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@HIDDEN, 76969 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) 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.
bug-gnu-emacs@HIDDEN:bug#76969; Package emacs.
Full text available.Received: (at 76969) by debbugs.gnu.org; 15 Mar 2025 14:06:54 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 15 10:06:54 2025 Received: from localhost ([127.0.0.1]:42973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ttSA8-00071F-EJ for submit <at> 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 <eliz@HIDDEN>) id 1ttSA1-0006zJ-LI for 76969 <at> 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 <eliz@HIDDEN>) 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@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <fdde0569-2d95-4933-9792-82b7fc6bb63e@HIDDEN> (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: <b8987709-43ea-47ed-8172-31a037e29d78@HIDDEN> <86senh2ren.fsf@HIDDEN> <15badabb-b95d-4c32-b5d5-4b98fa8db528@HIDDEN> <86wmct0yfj.fsf@HIDDEN> <a9e65d85-8887-4ed0-8ff2-302b0e1ca954@HIDDEN> <86bju41xoc.fsf@HIDDEN> <72d70cd7-5532-4139-a495-c8c8899820ae@HIDDEN> <86zfhoysxg.fsf@HIDDEN> <8e5d1340-9d4f-4892-b941-63de9f21f86f@HIDDEN> <86o6y2y72g.fsf@HIDDEN> <fdde0569-2d95-4933-9792-82b7fc6bb63e@HIDDEN> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@HIDDEN, 76969 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.6 (--) > Date: Sat, 15 Mar 2025 15:55:00 +0200 > Cc: 76969 <at> debbugs.gnu.org, sbaugh@HIDDEN > From: Dmitry Gutov <dmitry@HIDDEN> > > On 15/03/2025 11:30, Eli Zaretskii wrote: > >> Date: Sat, 15 Mar 2025 03:27:52 +0200 > >> Cc: 76969 <at> debbugs.gnu.org, sbaugh@HIDDEN > >> From: Dmitry Gutov <dmitry@HIDDEN> > >> > >> 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.
bug-gnu-emacs@HIDDEN:bug#76969; Package emacs.
Full text available.Received: (at 76969) by debbugs.gnu.org; 15 Mar 2025 13:55:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 15 09:55:14 2025 Received: from localhost ([127.0.0.1]:39971 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ttRyr-0004wk-Ks for submit <at> 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 <dmitry@HIDDEN>) id 1ttRyn-0004rz-Pp for 76969 <at> 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: <xms:t4bVZxRDRsq3LvDhNbnsTKCcf4C42G3dAzcHOcNGSLxto9wdaMzbgQ> <xme:t4bVZ6yjlLbduZM3rek_NDw83PpV48gH4bQAai48JjMAtsTlSfHN4nwo7uXmZz0Yv 04SWjJhWVIYdumue_s> X-ME-Received: <xmr:t4bVZ22QRkqdbgulvYz2xAmnlFB9OC8pzAA7BuxZ5iDijIpB0_g5dFIV4V7CiSGZWFcI> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddufeefkeelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddt vdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovh druggvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieek ueeftddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphht thhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdroh hrghdprhgtphhtthhopeejieelieelseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp thhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomh X-ME-Proxy: <xmx:t4bVZ5DYLPXvxLGr1-nVNVw2n3NEXyh5eZH4IbjcWhxISGhHINJ3ig> <xmx:t4bVZ6hZrW9FtjFLDDB0EpMWmxPc5IHDgR6KIIwi1HnZl0lx6tUwAw> <xmx:t4bVZ9q4IiPPZYyH-uZQui7VAGZ2Ri00uKdFQ8-0YGjzzI2ZetiSIw> <xmx:t4bVZ1gicg_Wm9zFjeFHQvadzBMSGEpJpEGR7EiRsZf2p8HsADvQrQ> <xmx:t4bVZ7ufcxtyY5APkEoWpAKgJzEkmyNXjCMcdtuto31x9iw2kTJOklU3> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 15 Mar 2025 09:55:02 -0400 (EDT) Message-ID: <fdde0569-2d95-4933-9792-82b7fc6bb63e@HIDDEN> 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 <eliz@HIDDEN> References: <b8987709-43ea-47ed-8172-31a037e29d78@HIDDEN> <86senh2ren.fsf@HIDDEN> <15badabb-b95d-4c32-b5d5-4b98fa8db528@HIDDEN> <86wmct0yfj.fsf@HIDDEN> <a9e65d85-8887-4ed0-8ff2-302b0e1ca954@HIDDEN> <86bju41xoc.fsf@HIDDEN> <72d70cd7-5532-4139-a495-c8c8899820ae@HIDDEN> <86zfhoysxg.fsf@HIDDEN> <8e5d1340-9d4f-4892-b941-63de9f21f86f@HIDDEN> <86o6y2y72g.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <86o6y2y72g.fsf@HIDDEN> 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@HIDDEN, 76969 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 15/03/2025 11:30, Eli Zaretskii wrote: >> Date: Sat, 15 Mar 2025 03:27:52 +0200 >> Cc: 76969 <at> debbugs.gnu.org, sbaugh@HIDDEN >> From: Dmitry Gutov <dmitry@HIDDEN> >> >> 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.
bug-gnu-emacs@HIDDEN:bug#76969; Package emacs.
Full text available.Received: (at 76969) by debbugs.gnu.org; 15 Mar 2025 09:30:50 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 15 05:30:50 2025 Received: from localhost ([127.0.0.1]:38835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ttNr0-0000Jh-2h for submit <at> 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 <eliz@HIDDEN>) id 1ttNqx-0000JS-Se for 76969 <at> 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 <eliz@HIDDEN>) 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@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <8e5d1340-9d4f-4892-b941-63de9f21f86f@HIDDEN> (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: <b8987709-43ea-47ed-8172-31a037e29d78@HIDDEN> <86senh2ren.fsf@HIDDEN> <15badabb-b95d-4c32-b5d5-4b98fa8db528@HIDDEN> <86wmct0yfj.fsf@HIDDEN> <a9e65d85-8887-4ed0-8ff2-302b0e1ca954@HIDDEN> <86bju41xoc.fsf@HIDDEN> <72d70cd7-5532-4139-a495-c8c8899820ae@HIDDEN> <86zfhoysxg.fsf@HIDDEN> <8e5d1340-9d4f-4892-b941-63de9f21f86f@HIDDEN> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@HIDDEN, 76969 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.6 (--) > Date: Sat, 15 Mar 2025 03:27:52 +0200 > Cc: 76969 <at> debbugs.gnu.org, sbaugh@HIDDEN > From: Dmitry Gutov <dmitry@HIDDEN> > > 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.
bug-gnu-emacs@HIDDEN:bug#76969; Package emacs.
Full text available.Received: (at 76969) by debbugs.gnu.org; 15 Mar 2025 01:28:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 14 21:28:04 2025 Received: from localhost ([127.0.0.1]:36933 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ttGJo-0002pi-3I for submit <at> 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 <dmitry@HIDDEN>) id 1ttGJl-0002p8-UU for 76969 <at> 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: <xms:m9fUZ6bRVljc0nI7WrZf2EafSrreNhbCr6NYRiBaOLkKEjhszkqzjg> <xme:m9fUZ9aDUB5xaQM3U7n0CyD65-YzP-MROa-J6gDlKdlkd-hbYTIZ4mbpCEILWx1tX q15Fs2XJGmpUkfGGNU> X-ME-Received: <xmr:m9fUZ0--YlNobLWahxN1yjcEKmltLt1InZpKuZLwptFdVAxO55bJZNQlCqMLYWrwdfvV> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddufedvfeelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddt vdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovh druggvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieek ueeftddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphht thhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdroh hrghdprhgtphhtthhopeejieelieelseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp thhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomh X-ME-Proxy: <xmx:m9fUZ8ptvW8VrN2ffzqaydTJvI5cfEZO0qclmBe1XnlL2scas85uyA> <xmx:m9fUZ1r_xmL8oywitf0bGVOBJ1yywymFJGLORlgyrr-F5l1zbBDIfg> <xmx:m9fUZ6QxBMzlyVrqCfA_ua-HV24wXHzKSk-XzYibjgZZDhJFebDJ_Q> <xmx:m9fUZ1oMMBBGJG4b2MoMx_qydLQa6kPR-aV9Ze3iu8RJ0dV2qy7Q7g> <xmx:nNfUZ8Wnu9XpFLNjHSsDTkcWFtu5aAl5av0GMvXziHf0VTMo30hnEgme> 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@HIDDEN> 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 <eliz@HIDDEN> References: <b8987709-43ea-47ed-8172-31a037e29d78@HIDDEN> <86senh2ren.fsf@HIDDEN> <15badabb-b95d-4c32-b5d5-4b98fa8db528@HIDDEN> <86wmct0yfj.fsf@HIDDEN> <a9e65d85-8887-4ed0-8ff2-302b0e1ca954@HIDDEN> <86bju41xoc.fsf@HIDDEN> <72d70cd7-5532-4139-a495-c8c8899820ae@HIDDEN> <86zfhoysxg.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <86zfhoysxg.fsf@HIDDEN> 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@HIDDEN, 76969 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) 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?
bug-gnu-emacs@HIDDEN:bug#76969; Package emacs.
Full text available.Received: (at 76969) by debbugs.gnu.org; 14 Mar 2025 07:26:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 14 03:26:44 2025 Received: from localhost ([127.0.0.1]:59894 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tszRL-0001go-VQ for submit <at> 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 <eliz@HIDDEN>) id 1tszRJ-0001gZ-MU for 76969 <at> 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 <eliz@HIDDEN>) 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@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <72d70cd7-5532-4139-a495-c8c8899820ae@HIDDEN> (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: <b8987709-43ea-47ed-8172-31a037e29d78@HIDDEN> <86senh2ren.fsf@HIDDEN> <15badabb-b95d-4c32-b5d5-4b98fa8db528@HIDDEN> <86wmct0yfj.fsf@HIDDEN> <a9e65d85-8887-4ed0-8ff2-302b0e1ca954@HIDDEN> <86bju41xoc.fsf@HIDDEN> <72d70cd7-5532-4139-a495-c8c8899820ae@HIDDEN> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 76969 Cc: sbaugh@HIDDEN, 76969 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.6 (--) > Date: Thu, 13 Mar 2025 23:21:59 +0200 > Cc: 76969 <at> debbugs.gnu.org, sbaugh@HIDDEN > From: Dmitry Gutov <dmitry@HIDDEN> > > 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.
bug-gnu-emacs@HIDDEN:bug#76969; Package emacs.
Full text available.Received: (at 76969) by debbugs.gnu.org; 13 Mar 2025 21:22:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 13 17:22:14 2025 Received: from localhost ([127.0.0.1]:58536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tsq0M-0006Hm-Ad for submit <at> 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 <dmitry@HIDDEN>) id 1tsq0J-0006HV-Ll for 76969 <at> 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: <xms:e0zTZ7RTzSSaFX2S4_Qr5AkWnst_WfYePBIU8rTkaBOy-9KFjUpIXw> <xme:e0zTZ8x3hq5ujj30LJVkeM-YLHuVH8_039moBGvjEaQs_-kfcFjiVGIVmrd_cOLxL IVzl6XaOpb3ErKsSQE> X-ME-Received: <xmr:e0zTZw2iUm4xqjAeMTvhvKHTqIyX0xOXDRGt_hSbZZYUdFQhbifiaOOweRdk6hxpgKOd> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduvdeltdduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddt vdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovh druggvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieek ueeftddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphht thhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdroh hrghdprhgtphhtthhopeejieelieelseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp thhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomh X-ME-Proxy: <xmx:e0zTZ7AZpiWp3L7Q01ghcpiH62RZxhhLZmGlmIa_hdIk5e5z3JK4cQ> <xmx:e0zTZ0jUUM3KCLmsn_rEMZ4ok7dRUCd4tlMjeS0hOzyLh9gJ-_2y5Q> <xmx:e0zTZ_quaa0aXmhweFNxXNhSftq1VqXkS2OaINdLKIpwj1dqrG6uvw> <xmx:e0zTZ_itSVbEUjvupVtAGZlkXP32J2HNTIzta-DEyJJIrwmkJi8hcg> <xmx:fEzTZ9s5F3Tc4fm8lTcNlIuKiSXmyqbZZjQr6U2IhLMSwaltXQka2iRH> 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@HIDDEN> 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 <eliz@HIDDEN> References: <b8987709-43ea-47ed-8172-31a037e29d78@HIDDEN> <86senh2ren.fsf@HIDDEN> <15badabb-b95d-4c32-b5d5-4b98fa8db528@HIDDEN> <86wmct0yfj.fsf@HIDDEN> <a9e65d85-8887-4ed0-8ff2-302b0e1ca954@HIDDEN> <86bju41xoc.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <86bju41xoc.fsf@HIDDEN> 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@HIDDEN, 76969 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) 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.
bug-gnu-emacs@HIDDEN:bug#76969; Package emacs.
Full text available.Received: (at 76969) by debbugs.gnu.org; 13 Mar 2025 20:38:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 13 16:38:45 2025 Received: from localhost ([127.0.0.1]:58404 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tspKG-0003kC-Rr for submit <at> 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 <eliz@HIDDEN>) id 1tspKE-0003js-Ve for 76969 <at> 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 <eliz@HIDDEN>) 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@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <ier4izwsn2p.fsf@HIDDEN> (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: <b8987709-43ea-47ed-8172-31a037e29d78@HIDDEN> <86senh2ren.fsf@HIDDEN> <15badabb-b95d-4c32-b5d5-4b98fa8db528@HIDDEN> <86wmct0yfj.fsf@HIDDEN> <a9e65d85-8887-4ed0-8ff2-302b0e1ca954@HIDDEN> <ier4izwsn2p.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76969 Cc: dmitry@HIDDEN, 76969 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Spencer Baugh <sbaugh@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, 76969 <at> 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.
bug-gnu-emacs@HIDDEN:bug#76969; Package emacs.
Full text available.
Received: (at 76969) by debbugs.gnu.org; 13 Mar 2025 20:30:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 13 16:30:49 2025
Received: from localhost ([127.0.0.1]:58371 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tspCb-0003Hx-6I
for submit <at> 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 <eliz@HIDDEN>) id 1tspCY-0003Hf-GA
for 76969 <at> 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 <eliz@HIDDEN>)
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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <a9e65d85-8887-4ed0-8ff2-302b0e1ca954@HIDDEN> (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: <b8987709-43ea-47ed-8172-31a037e29d78@HIDDEN>
<86senh2ren.fsf@HIDDEN> <15badabb-b95d-4c32-b5d5-4b98fa8db528@HIDDEN>
<86wmct0yfj.fsf@HIDDEN> <a9e65d85-8887-4ed0-8ff2-302b0e1ca954@HIDDEN>
X-Spam-Score: -1.6 (-)
X-Debbugs-Envelope-To: 76969
Cc: sbaugh@HIDDEN, 76969 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.6 (--)
> Date: Thu, 13 Mar 2025 21:30:15 +0200
> Cc: 76969 <at> debbugs.gnu.org, Spencer Baugh <sbaugh@HIDDEN>
> From: Dmitry Gutov <dmitry@HIDDEN>
>
> 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.
bug-gnu-emacs@HIDDEN:bug#76969; Package emacs.
Full text available.Received: (at 76969) by debbugs.gnu.org; 13 Mar 2025 20:16:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 13 16:16:56 2025 Received: from localhost ([127.0.0.1]:58325 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tsoz9-0002NZ-S4 for submit <at> 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 <sbaugh@HIDDEN>) id 1tsoz6-0002NC-2B for 76969 <at> debbugs.gnu.org; Thu, 13 Mar 2025 16:16:53 -0400 From: Spencer Baugh <sbaugh@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current In-Reply-To: <a9e65d85-8887-4ed0-8ff2-302b0e1ca954@HIDDEN> (Dmitry Gutov's message of "Thu, 13 Mar 2025 21:30:15 +0200") References: <b8987709-43ea-47ed-8172-31a037e29d78@HIDDEN> <86senh2ren.fsf@HIDDEN> <15badabb-b95d-4c32-b5d5-4b98fa8db528@HIDDEN> <86wmct0yfj.fsf@HIDDEN> <a9e65d85-8887-4ed0-8ff2-302b0e1ca954@HIDDEN> Date: Thu, 13 Mar 2025 16:16:46 -0400 Message-ID: <ier4izwsn2p.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=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 <eliz@HIDDEN>, 76969 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.6 (--) Dmitry Gutov <dmitry@HIDDEN> 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.
bug-gnu-emacs@HIDDEN:bug#76969; Package emacs.
Full text available.
Received: (at 76969) by debbugs.gnu.org; 13 Mar 2025 19:30:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 13 15:30:28 2025
Received: from localhost ([127.0.0.1]:58231 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tsoGB-0008Kh-U9
for submit <at> 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 <dmitry@HIDDEN>) id 1tsoG9-0008KJ-6w
for 76969 <at> 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: <xms:SzLTZ8qOv_l3UOag2u02rrClWand-OBGP0CwCX-CHQ2jiQIJeCrYBw>
<xme:SzLTZypkB4fB1l0_GxBYJrtVPXSNK00Y1C0nBNDmjX4qZ1WX_IMNQjQRBk9ZQN2c5
oxZ0j2AeDIDvj-l_4Y>
X-ME-Received: <xmr:SzLTZxO6O9yZVM5YqLG9TumAuXO6JnZr9VTrOLowY-Efc1ElvRCknhxUKkPTZHZAebB7>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduvdekjeelucetufdoteggodetrf
dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
gvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddt
vdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovh
druggvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieek
ueeftddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg
hmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphht
thhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdroh
hrghdprhgtphhtthhopeejieelieelseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp
thhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomh
X-ME-Proxy: <xmx:SzLTZz64ArfO6E9xbzv-NwvfayJw3ARt3qbeBzPUqz-J-YlI1VM1SA>
<xmx:SzLTZ77qGzcD_otNbcTzF8HWncX6ClGWCCdAqnRCXQ19vlA41ykh1Q>
<xmx:SzLTZzhD2DdbIUaX6gqRe2sUDsAQ0mQ2T0MqFUAQL616wHBPhobK4A>
<xmx:SzLTZ16Atg3RHLqyyJhwELv5RcSTM8m5VfXVx1blsFuBpb2FZDOosw>
<xmx:SzLTZ9nXYOlTOtaYCj3lqkPUT9Qa2bGRl_Nr5NaY9xKjlt_HGUDKRNvV>
Feedback-ID: i07de48aa:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
13 Mar 2025 15:30:18 -0400 (EDT)
Message-ID: <a9e65d85-8887-4ed0-8ff2-302b0e1ca954@HIDDEN>
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 <eliz@HIDDEN>
References: <b8987709-43ea-47ed-8172-31a037e29d78@HIDDEN>
<86senh2ren.fsf@HIDDEN> <15badabb-b95d-4c32-b5d5-4b98fa8db528@HIDDEN>
<86wmct0yfj.fsf@HIDDEN>
Content-Language: en-US
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <86wmct0yfj.fsf@HIDDEN>
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 <sbaugh@HIDDEN>, 76969 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
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).
bug-gnu-emacs@HIDDEN:bug#76969; Package emacs.
Full text available.
Received: (at 76969) by debbugs.gnu.org; 13 Mar 2025 14:59:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 13 10:59:09 2025
Received: from localhost ([127.0.0.1]:57650 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tsk1d-0004g3-Bt
for submit <at> 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 <eliz@HIDDEN>) id 1tsk1b-0004fk-7B
for 76969 <at> 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 <eliz@HIDDEN>)
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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <15badabb-b95d-4c32-b5d5-4b98fa8db528@HIDDEN> (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: <b8987709-43ea-47ed-8172-31a037e29d78@HIDDEN>
<86senh2ren.fsf@HIDDEN> <15badabb-b95d-4c32-b5d5-4b98fa8db528@HIDDEN>
X-Spam-Score: -1.6 (-)
X-Debbugs-Envelope-To: 76969
Cc: 76969 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.6 (--)
> Date: Thu, 13 Mar 2025 14:10:36 +0200
> Cc: 76969 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry@HIDDEN>
>
> 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.
bug-gnu-emacs@HIDDEN:bug#76969; Package emacs.
Full text available.
Received: (at 76969) by debbugs.gnu.org; 13 Mar 2025 12:10:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 13 08:10:49 2025
Received: from localhost ([127.0.0.1]:54042 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tshOi-0004NZ-QM
for submit <at> 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 <dmitry@HIDDEN>) id 1tshOf-0004NG-7k
for 76969 <at> 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: <xms:P8vSZxK4RSIOy0RPS3FT2zcTkw1eS62ExkhCjnq1Bub7xpvXwAPeYQ>
<xme:P8vSZ9Knnc_8lg9OMNWD83OwTiI3VIP--ObE2ueFSn6p-6uvWInRe33ljn2f9BaPj
NubC_Vk_HbPknG_W1s>
X-ME-Received: <xmr:P8vSZ5t439NitaXOO578NbzxGfEaePn0qUM-_Hv9DYoN5U8edyp3P9Kzz8rOD8jZnZB2>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduvdejleduucetufdoteggodetrf
dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
gvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddt
vdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovh
druggvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieek
ueeftddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg
hmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphht
thhopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdroh
hrghdprhgtphhtthhopeejieelieelseguvggssghughhsrdhgnhhurdhorhhg
X-ME-Proxy: <xmx:P8vSZyYISdpTw4AN917kKDxUDoS_ugRYfBHEtgU-brcUyAq14qLw7Q>
<xmx:P8vSZ4ZgtkET0aHciVQ84KhawivVEek0fHnZB0_eD54cDiTDLP0vbQ>
<xmx:P8vSZ2AZzoWLgMi6NSeF4Rt8e53d7mPs59gYWTlTkquTmFGxB3imBQ>
<xmx:P8vSZ2afqjpzg2AABiIsHgle2zk-dJ6nVQAmwM6HfXcW2QWf3Eugnw>
<xmx:P8vSZ3m4nqjJewqTvmmOAQEs8kqyTWMvtgUa90jnl37yUFb4PoX5OQmn>
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@HIDDEN>
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 <eliz@HIDDEN>
References: <b8987709-43ea-47ed-8172-31a037e29d78@HIDDEN>
<86senh2ren.fsf@HIDDEN>
Content-Language: en-US
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <86senh2ren.fsf@HIDDEN>
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 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
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.
bug-gnu-emacs@HIDDEN:bug#76969; Package emacs.
Full text available.
Received: (at 76969) by debbugs.gnu.org; 13 Mar 2025 09:47:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 13 05:47:55 2025
Received: from localhost ([127.0.0.1]:53777 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tsfAQ-0008RY-VL
for submit <at> 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 <eliz@HIDDEN>) id 1tsfAO-0008RK-0W
for 76969 <at> 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 <eliz@HIDDEN>)
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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <b8987709-43ea-47ed-8172-31a037e29d78@HIDDEN> (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: <b8987709-43ea-47ed-8172-31a037e29d78@HIDDEN>
X-Spam-Score: -1.6 (-)
X-Debbugs-Envelope-To: 76969
Cc: 76969 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.6 (--)
> Date: Wed, 12 Mar 2025 03:16:08 +0200
> From: Dmitry Gutov <dmitry@HIDDEN>
>
> 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.
bug-gnu-emacs@HIDDEN:bug#76969; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 12 Mar 2025 01:16:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 11 21:16:25 2025
Received: from localhost ([127.0.0.1]:46450 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tsAht-0005oc-IH
for submit <at> 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 <dmitry@HIDDEN>) id 1tsAhr-0005oK-IV
for submit <at> 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 <dmitry@HIDDEN>) id 1tsAhk-0002oP-Ah
for bug-gnu-emacs@HIDDEN; 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 <dmitry@HIDDEN>) id 1tsAhi-0004DC-45
for bug-gnu-emacs@HIDDEN; 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 <bug-gnu-emacs@HIDDEN>; 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: <xms:XODQZ3NDxhZIhAipX9ebRNUL3JbZtrzgktMzX83JxN3qjbg-GxREQw>
<xme:XODQZx8m_gLTbWw0X_Dd_2F3KIbq6uKVRjWxy2xBHdi92TS0ByMSOcKNlSCqrAmLi
26_WzaFJKEvP25Q-AY>
X-ME-Received: <xmr:XODQZ2Rtapr2-OUMsvI2xf47uIpeeRBOmXfBv7UIBLBRWGJS6aiin7fQrmAHwZvGISeB>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduvdefjedvucetufdoteggodetrf
dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefkff
ggfgfvhffutgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcu
oegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvghrnhepfeekfeeghf
ejveehkedtgefhffejgefgudetgfeguefhteekudeivefghfekgfevnecuvehluhhsthgv
rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtoh
hvrdguvghvpdhnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhuthdprhgtphht
thhopegsuhhgqdhgnhhuqdgvmhgrtghssehgnhhurdhorhhg
X-ME-Proxy: <xmx:XODQZ7vXqzIY7DfCA0qtOeClFT-fwimkub3mfl8dhUrkXxjZkcNXig>
<xmx:XODQZ_egpD3AAdfWHARNXyILTv2_glDkgPiu9vIR5xaJrJUurzUFsA>
<xmx:XODQZ30PUT4DoBWYgIC7M35jW2WbSzPm5uONr8rPK-TkejDjjO1FKw>
<xmx:XODQZ793R3wMC8QxqF8R0B3fI40FdZhMBVNC3Qm_JUN1JLfvGIRZYA>
<xmx:XODQZ3H_gbEzsPTLK4sRQYTy-zbiJUwzY4TYqRt1VYiFbJstpKu4TnUG>
Feedback-ID: i07de48aa:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
<bug-gnu-emacs@HIDDEN>; Tue, 11 Mar 2025 21:16:11 -0400 (EDT)
Message-ID: <b8987709-43ea-47ed-8172-31a037e29d78@HIDDEN>
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@HIDDEN
From: Dmitry Gutov <dmitry@HIDDEN>
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@HIDDEN;
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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 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)
Dmitry Gutov <dmitry@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#76969; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.