GNU bug report logs -
#76969
kill-buffer fails silently when a thread exists where it's current
Previous Next
Full log
Message #35 received at 76969 <at> debbugs.gnu.org (full text, mbox):
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?
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.