--- Begin Message ---
|
Subject: |
30.0.50; thread_check_current_buffer |
|
Date: |
Sat, 05 Aug 2023 14:51:26 +0200 |
This test fails
(ert-deftest tmp-buf ()
(let (buf)
(with-temp-buffer
(setq buf (current-buffer))
(make-thread (lambda ())))
(should-not (buffer-live-p buf))))
when executed with
emacs -Q --batch -l tmp-buf.el -f ert-run-tests-batch-and-exit
The reason seems to be, that thread_check_current_buffer returns true
and hence kill_buffer simply returns without doing anything.
I don't understand why this check is there, but it's quite annoying in
practice. E.g. ert--run-test-internal uses with-temp-buffer too, so if
make-thread is used in a test, the temporary buffers will hang around
and pile up.
In GNU Emacs 30.0.50 (build 26, x86_64-pc-linux-gnu, GTK+ Version
3.24.37, cairo version 1.16.0) of 2023-08-04 built on caladan
Repository revision: 4de3198c10c4efaeaffdf43ba5e5b0f1729a7f09
Repository branch: interruptible-condition-wait
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Debian GNU/Linux 12 (bookworm)
Configured using:
'configure --enable-checking=yes --with-xpm=ifavailable
--with-gif=ifavailable 'CFLAGS=-g -O1''
Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBSELINUX
LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG SECCOMP SOUND
SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 GTK3
ZLIB
Important settings:
value of $LANG: C.UTF-8
locale-coding-system: utf-8-unix
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#65095: 30.0.50; thread_check_current_buffer |
|
Date: |
Sat, 05 Aug 2023 18:32:34 +0300 |
> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: 65095@debbugs.gnu.org
> Date: Sat, 05 Aug 2023 16:42:46 +0200
>
> >> I don't understand why this check is there
> >
> > How would kill-buffer know whether it's okay to kill a buffer that is
> > current in another thread? When we kill the current buffer in the
> > current thread, we do quite a bit of juggling to replace it with some
> > other, and punt if not possible. We also "do nothing" if the buffer
> > to be killed is the currently active minibuffer or the sole visible
> > buffer. So this "do nothing" in this case is not without precedent,
> > and cannot be just removed without having some non-trivial code in its
> > stead, right?
>
> Well, then I guess this is just something that one has to accept when
> using threads. One more reason not to use threads.
>
> You can close the bug.
Done, thanks.
--- End Message ---