GNU bug report logs - #76969
kill-buffer fails silently when a thread exists where it's current

Previous Next

Full log

Message #47 received at 76969 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> janestreet.com, 76969 <at> debbugs.gnu.org
Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where
 it's current
Date: Sun, 16 Mar 2025 01:29:00 +0200

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.