GNU bug report logs -
#76969
kill-buffer fails silently when a thread exists where it's current
Previous Next
Full log
Message #44 received at 76969 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 15 Mar 2025 15:55:00 +0200
> Cc: 76969 <at> debbugs.gnu.org, sbaugh <at> janestreet.com
> From: Dmitry Gutov <dmitry <at> gutov.dev>
>
> 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 <at> janestreet.com
> >> From: Dmitry Gutov <dmitry <at> gutov.dev>
> >>
> >> 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.
This bug report was last modified 93 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.