From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 05 08:51:47 2023 Received: (at submit) by debbugs.gnu.org; 5 Aug 2023 12:51:47 +0000 Received: from localhost ([127.0.0.1]:56063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSGl1-0005I5-FG for submit@debbugs.gnu.org; Sat, 05 Aug 2023 08:51:47 -0400 Received: from lists.gnu.org ([2001:470:142::17]:45840) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSGkx-0005Hl-J5 for submit@debbugs.gnu.org; Sat, 05 Aug 2023 08:51:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSGks-0006Lb-51 for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2023 08:51:38 -0400 Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qSGkp-0006Z2-3I for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2023 08:51:37 -0400 Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-3179ed1dfbbso2624689f8f.1 for ; Sat, 05 Aug 2023 05:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691239893; x=1691844693; h=mime-version:message-id:date:subject:to:from:from:to:cc:subject :date:message-id:reply-to; bh=WVNMHPeQXVAuF0u89gyS69/C7pInrpKLAYkshEbdo5c=; b=fkKG2jWbu85IkJMPTFqK1TfgXUwkcclU4oiIb1B/kjyTXQxCQU+v+SDl01vDzTqPFK +P0SljyWpr0vWO/ksBLFUVClA2O4knR6OBJVeIbLqqNNe24RTIF7AFWIuhiJ2wVaxKdY c4MVEoMBzt2stvIpJy+VfcRdz2xr8YMfs9UlssEv8SMcdiLXCz7ddGKSZVq3yodCAlP+ B8Dc/5wFKhTP0IE7cksr9DVq01BKE/dRcKZA8unDzW6kT44mnVhdvDenJIQgYKz6MCPX nLyPCgwQgoyi4rEuMsmv1kBlmaoqiDX8n4TZ4spS9UDE56w8Z1fGGcpFxhF0GteCdmiO izFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691239893; x=1691844693; h=mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=WVNMHPeQXVAuF0u89gyS69/C7pInrpKLAYkshEbdo5c=; b=kV1mQjAe6pvihZ1Xe0C0V/MbV8cJrLT4sbcChyt5PDqH9axZaUSgJP5pWLfn4T5glN k1Hg0EnBYjmOTVCtnc2uXRVh7wgGap1P+JQuOjxZtZ54Mk2EdY1KdN3HMDDVGfYFN3Cw LD7D4odwePuhlKvJ84m5SHqseMgxt80Dd5XT/7FcxGy6dottWaACa9KP+WOhdwHhVz0k HOV7s6f+RvC2lA9LBpLUYKte6Y7aUYLtaWeF3IVYorIeyrQF32DPoKpR3qOF4yBfM8/C uuU+LRQHLEx09Lo2mgRhPEbDD45HikVCmtRWjpNZx1yFSV9HHQzbWayDkEfZSdw9c0o5 u5xQ== X-Gm-Message-State: AOJu0Yytkw6FLVa8QTc4L/MItjNYEheX8GY/8BGfSQZ3hd165fs46NoN 9uBu/uHC7bRMuvNMNlYLigx7DZCVmyE= X-Google-Smtp-Source: AGHT+IGzsW/k1I0nnHME6B/jXXEdDHYICuqhCTh9LV/TEAzBg3fUtO8Klt708v2a6I7iXjX5znducA== X-Received: by 2002:a5d:44d1:0:b0:317:5ba8:ac6 with SMTP id z17-20020a5d44d1000000b003175ba80ac6mr3085199wrr.8.1691239892630; Sat, 05 Aug 2023 05:51:32 -0700 (PDT) Received: from caladan (dialin-228086.xdsl.raiffeisen.net. [195.254.228.86]) by smtp.gmail.com with ESMTPSA id x12-20020adfec0c000000b0031274a184d5sm5069559wrn.109.2023.08.05.05.51.31 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 05 Aug 2023 05:51:32 -0700 (PDT) From: Helmut Eller To: bug-gnu-emacs@gnu.org Subject: 30.0.50; thread_check_current_buffer Date: Sat, 05 Aug 2023 14:51:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::436; envelope-from=eller.helmut@gmail.com; helo=mail-wr1-x436.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 05 09:11:41 2023 Received: (at 65095) by debbugs.gnu.org; 5 Aug 2023 13:11:41 +0000 Received: from localhost ([127.0.0.1]:56083 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSH4H-0005oT-G7 for submit@debbugs.gnu.org; Sat, 05 Aug 2023 09:11:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55724) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSH4E-0005oA-1G for 65095@debbugs.gnu.org; Sat, 05 Aug 2023 09:11:40 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSH48-0001u9-Pn; Sat, 05 Aug 2023 09:11:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=dzgp1hAQ8jTrfjzgDm8+z6HrsfpL/5KFX0C3NjhT7iQ=; b=UkCsnHiIG/0/ IlWVaP+bA1o9bnd4ZuGvLMk7rKo6w6Nh96NZmqHhZF7QQBdfVjz0CbMkxAxE8rFGttaEBKEt5nTw7 3LEvnyywEYQFd1iI2UcYcBt58jnFUREAnaVdTKWH5wDKUqX55VgY1Sc8yCNTJ0AfQ5I8M0A8dyq9g FVtOsgt2ijENBVrO06seSugIReB6KW8TQfQ0f5Iojy2d/11CQgPMbbh1krV3E+kNL0j4LlV6z2f/W QclNUvpZb2MPuYdVG72wcj6GU80NQUEJUbX3/tmDXMojoruayCLuAAypl3XUK8qw2ExCgZg9IRQXg 3xN/Jens5U3Yp6ypDaIeVQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSH48-0006kq-9T; Sat, 05 Aug 2023 09:11:32 -0400 Date: Sat, 05 Aug 2023 16:11:47 +0300 Message-Id: <83cz01skfg.fsf@gnu.org> From: Eli Zaretskii To: Helmut Eller In-Reply-To: (message from Helmut Eller on Sat, 05 Aug 2023 14:51:26 +0200) Subject: Re: bug#65095: 30.0.50; thread_check_current_buffer References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65095 Cc: 65095@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Helmut Eller > 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 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? > 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. The tests should arrange for deleting the buffer when no longer needed. The simplest is to have the thread kill its current buffer before it (the thread) exits. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 05 10:42:55 2023 Received: (at 65095) by debbugs.gnu.org; 5 Aug 2023 14:42:55 +0000 Received: from localhost ([127.0.0.1]:57936 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSIUZ-0000OA-3a for submit@debbugs.gnu.org; Sat, 05 Aug 2023 10:42:55 -0400 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]:60864) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSIUY-0000Nv-0P for 65095@debbugs.gnu.org; Sat, 05 Aug 2023 10:42:54 -0400 Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2b9fa64db41so48508341fa.1 for <65095@debbugs.gnu.org>; Sat, 05 Aug 2023 07:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691246568; x=1691851368; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=jw1HG2mOVL03UFIeJ1hDV6NJrEgtKgaWE7SB0LN7BVo=; b=FHoCFRtp/JOm7j/Gjezig0NSh63R22VMRMWlNG7+wRKVdVA++zIQWwP4pXGGnqbOYW io1XmaMLkBeAYx8re+MSFqfr3yqK0SdiwYnXm12P+YiyKm+tug8/e7u6uK7dUa3YpoA/ 1Clx4U4Lopn5NCAPPqnGREnYg/aGKmQIYixaRw2TZXwOCPLXAKieAlcm3LCh2HjB2YcR C+rG+N1+zIxdDyhiLUAQZuwNtEIVLK6+3mZTw8dxO0pa9hpcy29Kkyp1m0pUh8/DKFhE onyDxW+GXjf+nyEEOGM+MmMH2PSwUYdqBlYpAZlvHze94gKxEbeXqWGz2lXwrH0EYIBs Qfew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691246568; x=1691851368; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=jw1HG2mOVL03UFIeJ1hDV6NJrEgtKgaWE7SB0LN7BVo=; b=f5mlt5rPHmA0a6Z4wfpCfAsUfm+tCBL8EjF2kac+xO+xqjcvUPYb7VYmzc1Bl6C8xW b/pgP/OH1ZEaLAZFwWzH9Sf1WjBosO0NDIoiRR4pebOsuyX+dlc6bexIe57KeF0imto4 iQ4SvSbOTGZvw6rukceQGP4pbf7l1onLuEcnNWK/ow4TMCoquD+n3JUACbn1rRbVpK1M HFcDpidjhbqaKh9Qgp26hKrJSqJycDBlEswJ41aYPRmzVGsBzLNhkxz1lC0YpkrQZXs1 lFuPB4D/VW6CWi4KFYynNb1ArWeYQSMWoL5QWShWeerFDlaT1RsX6kTgBG6JV0CQvr1M XptQ== X-Gm-Message-State: AOJu0Yxbpm8o7LtI25aqLJL8kgCqI0IRFZKmQLC8MJpI5ZXtW0Jfkb00 JblKhR3/WwJ7VN+0Bt5b37AJJyoTbAA= X-Google-Smtp-Source: AGHT+IGn8hfo9SA0a2McTwK0/fR12XEIbl10PyEqwDxRLtoxe+DZssu9rz4dKfZYBhVt5byaThT0tQ== X-Received: by 2002:a05:651c:c3:b0:2b9:2e85:2fa0 with SMTP id 3-20020a05651c00c300b002b92e852fa0mr3306708ljr.15.1691246567728; Sat, 05 Aug 2023 07:42:47 -0700 (PDT) Received: from caladan (dialin-228086.xdsl.raiffeisen.net. [195.254.228.86]) by smtp.gmail.com with ESMTPSA id g6-20020a056000118600b00314398e4dd4sm5260548wrx.54.2023.08.05.07.42.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 05 Aug 2023 07:42:47 -0700 (PDT) From: Helmut Eller To: Eli Zaretskii Subject: Re: bug#65095: 30.0.50; thread_check_current_buffer In-Reply-To: <83cz01skfg.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 05 Aug 2023 16:11:47 +0300") References: <83cz01skfg.fsf@gnu.org> Date: Sat, 05 Aug 2023 16:42:46 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65095 Cc: 65095@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> 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. Helmut From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 05 11:32:26 2023 Received: (at 65095-done) by debbugs.gnu.org; 5 Aug 2023 15:32:26 +0000 Received: from localhost ([127.0.0.1]:57971 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSJGT-0001kU-W1 for submit@debbugs.gnu.org; Sat, 05 Aug 2023 11:32:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52150) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSJGS-0001kH-AB for 65095-done@debbugs.gnu.org; Sat, 05 Aug 2023 11:32:24 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSJGN-0002Q3-3L; Sat, 05 Aug 2023 11:32:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=rYdU8fTu/AepnJSk7K4H5ATKodR2BCWLCUI9QbEtlyo=; b=RNC14HQ/4aXC AIizm2C3XRdY533juy4zHJl8KuItyeaTmTzMIloqjC8aq7OwnlVm6cN8LYyceoXjry8sO1dEtX7fQ RMx7GI/GqkO8mKmkq2asf7VcTNAC7f7WzJbdmH0+tLYAFFU6HNbwMAwSDsFR8UINAQLguNX5noU5D jPOB8NWT6OfB3/UyLp+F7QOweZR45hyrpTdRc7we1DgYKuiR3XHqGhrm50jHPwqDNTHSgNeb2f3oK GNanBxtNs9uFKrODpTGY5YaGN167R3R6vm4nSvr6oaqJDieXWZwhCDEx5IK4PYPijxm7DWnRgjrCr 2Ywh4ePaPBSmX0PQGO85gg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSJGM-0007DU-9y; Sat, 05 Aug 2023 11:32:18 -0400 Date: Sat, 05 Aug 2023 18:32:34 +0300 Message-Id: <831qghsdwt.fsf@gnu.org> From: Eli Zaretskii To: Helmut Eller In-Reply-To: (message from Helmut Eller on Sat, 05 Aug 2023 16:42:46 +0200) Subject: Re: bug#65095: 30.0.50; thread_check_current_buffer References: <83cz01skfg.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65095-done Cc: 65095-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Helmut Eller > 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. From unknown Tue Aug 12 08:32:26 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 03 Sep 2023 11:24:09 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator