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 18/07/2025 09:24, Eli Zaretskii wrote:
>> Date: Fri, 18 Jul 2025 03:23:43 +0300
>> Cc: sbaugh <at> janestreet.com, 76969 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dmitry <at> gutov.dev>
>>
>>> . I think we should add an optional argument to make-thread, because
>>> calling a function to change the buffer_killable_p attribute might
>>> be too late (I'm not against having the function as well)
>>
>> Do you think there is a chance for the thread to be started between the
>> 'make-thread' and 'thread-set-buffer-killable' calls, even if they go
>> one after another?
>
> No. But it makes no sense to provide a separate interface if it must
> always be called immediately after make-thread, or else should be
> expected to be unreliable.
>
>> I considered making it a keyword argument of 'make-thread' but it seems
>> like it might not interest most callers, and so clutter the definition
>> (I couldn't come up with a less awkward name either). Not a strong
>> opinion, though.
>
> There's no need for keyword arguments. make-thread has just 2
> arguments as of now; adding one more is not going to make the calls
> awkward, especially if most callers will never pass that additional
> argument.
All right.
So if we make it an optional argument of 'make-thread', and the default
is for thread's buffer to be killable, that might call for a name change
(flipping the meaning).
Should it be
(make-thread FUNCTION &optional NAME BUFFER-PROTECTED)
?
With default nil and other possible values 't' and 'kill-silently'.
This bug report was last modified 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.