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

Previous Next

Full log

View this message in rfc822 format

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

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: Dmitry Gutov <dmitry <at> gutov.dev>,  76969 <at> debbugs.gnu.org
> 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.

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.

Previous Next

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