Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current

From: Dmitry Gutov <[email-masked]>
Date: Sat, 15 Mar 2025 03:27:52 +0200

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?