GNU bug report logs - #76969
kill-buffer fails silently when a thread exists where it's current

Previous Next

Full log

Message #89 received at 76969 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 76969 <at> debbugs.gnu.org
Subject: Re: bug#76969: kill-buffer fails silently when a thread exists
 where it's current
Date: Wed, 23 Jul 2025 16:41:42 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Wed, 23 Jul 2025 04:39:33 +0300
>> Cc: sbaugh <at> janestreet.com, 76969 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dmitry <at> gutov.dev>
>> 
>> On 22/07/2025 15:54, Eli Zaretskii wrote:
>> >> 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)
>> >>
>> >> ?
>> > I'd prefer to call that argument BUFFER-DISPOSITION.
>> 
>> I had to google it just now. A term from POSIX signals?
>
> Or from email messages.
>
>> Makes certain sense.
>> 
>> Seems like the default value would have to be nil, though, if it's 
>> passed as an optional argument to a function.
>
> Yes.  But given that this isn't a simple boolean, what it means when
> disposition = nil is open to interpretation, and the doc string should
> say clearly what that means.
>
>> Are we okay with nil meaning "thread's buffer is killed and sent a 
>> signal", t meaning "thread's buffer is never killed" and 'silently' 
>> meaning "thread's buffer is killed without a signal"?
>
> Maybe.  I'm not sure there's a definite agreement about the default.

Just as one vote, I'm in favor of "thread's buffer is killed and sent a
signal" being the default behavior.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.