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
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 4 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.