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

Previous Next

Full log

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 76969 <at> debbugs.gnu.org
Subject: Re: bug#76969: kill-buffer fails silently when a thread exists
 where it's current
Date: Mon, 17 Mar 2025 15:17:09 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Sun, 16 Mar 2025 01:29:00 +0200
>> Cc: 76969 <at> debbugs.gnu.org, sbaugh <at> janestreet.com
>> From: Dmitry Gutov <dmitry <at> gutov.dev>
>> 
>> 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.

Previous Next

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