From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 09 05:16:17 2023 Received: (at submit) by debbugs.gnu.org; 9 Sep 2023 09:16:17 +0000 Received: from localhost ([127.0.0.1]:46093 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qeu4e-00015n-RD for submit@debbugs.gnu.org; Sat, 09 Sep 2023 05:16:17 -0400 Received: from lists.gnu.org ([2001:470:142::17]:33518) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qeu4c-00015a-7S for submit@debbugs.gnu.org; Sat, 09 Sep 2023 05:16:15 -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 1qeu4T-0000YO-Kr for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2023 05:16:06 -0400 Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qeu4Q-0007s3-2z for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2023 05:16:05 -0400 Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-400a087b0bfso29662885e9.2 for ; Sat, 09 Sep 2023 02:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694250960; x=1694855760; darn=gnu.org; h=mime-version:message-id:date:subject:to:from:from:to:cc:subject :date:message-id:reply-to; bh=TtRS4MWLPlfYY69MZoR9ZMNe921j/3O1cX4DdTOan2U=; b=hz+OX2g765yRRLfkXuFv7DKkwu1EkLbolGIq7K3SNQge4pQ9skVjjkJ2SrYziFiFVr TEx1Oj+ByhgfJ6IXFZ0UJIKOPYrrvVgAfZcpiIP7Imt1TE4Ha85lurdVTy2DiuUjtUTi gDnAbqCrIszfAmgks43PLcVqrSI0SApYWx9L4OXX4mJRV9b5uCGBj6TtXCbDbdqSr0Hl COabFZHf8Xd/gwW71dDdrHPI8W2K/S/yOzDASLc4gqb3xcBvcMB4kD2RihPHtTTYgMSy eTaM40vN1IWdCLo5Gn/9qFIcZPaRlVsrnG1HfRYAcQNs0TZzLpEjGbE0bnyWavnuL04I sz1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694250960; x=1694855760; h=mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=TtRS4MWLPlfYY69MZoR9ZMNe921j/3O1cX4DdTOan2U=; b=m46w+ejxQd/RKxxhlKgOckwFhwYjVyQfO57OgY8pjIUp3qAM0Qrw+a+cQhZgQAgfnM sJOtIgJ+FGk1kaCP40WCXT0bmDT5Qsyk41neb6kYZJZD2GyP3G3ip6he+p3901Bj3b9z snYt4wEQ1KrhMuyFMWaN22OM30lk2tr3WqFogbI3RDPJHuCWn9RAEDYqAdxdVP9hWKhk Nz9QqRdauHv795xh83HXHbagJGOpbjzpF0cQGdjwGpwZmEnBJErKcrn+91tmA9opilnD gJQMD3DHAXtD/Ca4vNAfmE5ruOUz6Ev0f//DfeH73zDKFiYPpCFNdptx+0jAkUMDzufD okAw== X-Gm-Message-State: AOJu0YxCOD0H6UPJAtjVPGgOI5Yeu4rQTk0b7luT1EvzVUuJA1aXaGnW a601ekyUT8kJLob5+oUiDmmlCZ4+neo= X-Google-Smtp-Source: AGHT+IF4t4mD+KwMjprfZMprCOWZQi32tdA1zFv2VMyCwydyVqSTBs+2NB6778Benmk5d96kwRuCvg== X-Received: by 2002:a7b:ce85:0:b0:401:bf62:9456 with SMTP id q5-20020a7bce85000000b00401bf629456mr3732573wmj.8.1694250959686; Sat, 09 Sep 2023 02:15:59 -0700 (PDT) Received: from caladan ([31.177.119.112]) by smtp.gmail.com with ESMTPSA id k22-20020a05600c0b5600b003fc0505be19sm4053284wmr.37.2023.09.09.02.15.58 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 Sep 2023 02:15:59 -0700 (PDT) From: Helmut Eller To: bug-gnu-emacs@gnu.org Subject: 30.0.50; Debugger in non-main threads Date: Sat, 09 Sep 2023 11:15:52 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::335; envelope-from=eller.helmut@gmail.com; helo=mail-wm1-x335.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 (/) When the debugger is entered in a non-main thread, like so emacs -Q --eval '(make-thread (lambda() (debug)))' Then debugger-quit doesn't work as usual, instead it prints debugger-quit: No catch for tag: top-level, nil or it prints Back to top level but doesn't actually close the debugger window. Also, debugger-continue doesn't work as usual, instead it sometimes prints: debugger-continue: No catch for tag: exit, nil sometimes it prints: Continuing. without deleting the debugger window, sometimes it manages to leave the debugger. If Emacs is started with "emacs -Q -nw" then the behaviour seems to be a bit more uniform, but equally useless. Helmut In GNU Emacs 30.0.50 (build 192, x86_64-pc-linux-gnu, GTK+ Version 3.24.37, cairo version 1.16.0) of 2023-09-09 built on caladan Repository revision: e865ee05d7f974bace724dd241a311c753006933 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 09 07:14:38 2023 Received: (at 65837) by debbugs.gnu.org; 9 Sep 2023 11:14:38 +0000 Received: from localhost ([127.0.0.1]:46285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qevvC-0004JA-Ec for submit@debbugs.gnu.org; Sat, 09 Sep 2023 07:14:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38484) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qevv9-0004Iw-Lw for 65837@debbugs.gnu.org; Sat, 09 Sep 2023 07:14:36 -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 1qevv1-0005tI-Ff; Sat, 09 Sep 2023 07:14:27 -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=+vwqsYHJaxfo+YOcyzV1q992Sami1MHHurbuVC8oK8U=; b=JV2Pyi70h/oN zjZaUmnZh8Th0X8O5js2hkYOO/PQCkypPrsqSWiwtK1pCCjCyc05ylKwz2UT5dZ9x2iuI9eV0gEZm /ghd2uA1sV1Q9tgjx5ZA/4mb1+YIV/I84N/2ZFUjrrPWQKG99vJ3uZX8S738Ut77S5eA2oAK79Z0h bW3qzdrhrfaAzu0af7a+ND+4ZtDYnYHyhYXiy9ESspbXkHv+o0LcTA2tlMH3U7RdZcmKRqw9J3Y9/ hcwUoo6jBxd4hVxj3edTKcHvco1KgUMB7WM4flFoX0z0/XN8CsroH1bN6Z/ZqS8AW/XtBCaYw84Ag M7ttWREXh7qEbbpZ6xm2oQ==; Date: Sat, 09 Sep 2023 14:14:20 +0300 Message-Id: <83bkebvbsj.fsf@gnu.org> From: Eli Zaretskii To: Helmut Eller In-Reply-To: (message from Helmut Eller on Sat, 09 Sep 2023 11:15:52 +0200) Subject: Re: bug#65837: 30.0.50; Debugger in non-main threads References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65837 Cc: 65837@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, 09 Sep 2023 11:15:52 +0200 > > When the debugger is entered in a non-main thread, like so > > emacs -Q --eval '(make-thread (lambda() (debug)))' > > Then debugger-quit doesn't work as usual, instead it prints > > debugger-quit: No catch for tag: top-level, nil > > or it prints > > Back to top level > > but doesn't actually close the debugger window. > > Also, debugger-continue doesn't work as usual, instead it sometimes prints: > > debugger-continue: No catch for tag: exit, nil > > sometimes it prints: > > Continuing. > > without deleting the debugger window, sometimes it manages to leave the > debugger. > > If Emacs is started with "emacs -Q -nw" then the behaviour seems to be a > bit more uniform, but equally useless. Yes, error handling in non-main threads is generally rudimentary and barely useful. For example, if a thread signals an error, it simply silently exits and leaves the error form in a variable that can be accessed via thread-last-error. AFAIR, it is not trivial to improve the thread error handling significantly, but patches are welcome, of course. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 09 11:35:38 2023 Received: (at 65837) by debbugs.gnu.org; 9 Sep 2023 15:35:38 +0000 Received: from localhost ([127.0.0.1]:48311 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qezzl-0008C1-OJ for submit@debbugs.gnu.org; Sat, 09 Sep 2023 11:35:38 -0400 Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]:59422) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qezzg-0008Bk-MP for 65837@debbugs.gnu.org; Sat, 09 Sep 2023 11:35:36 -0400 Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-401da71b7faso35203545e9.2 for <65837@debbugs.gnu.org>; Sat, 09 Sep 2023 08:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694273724; x=1694878524; darn=debbugs.gnu.org; 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=zGfImGE2i0Oa/11mM60HNUIqRHTuhK49A+miOddTXek=; b=LXOv9oXZkVlUhlJAYvJdOnEL9ph7nfcY7bBGUYxi2xEGen2vRPuHWLOtrYPKs8wORn y/ZC3zs8MIYEnaPU/FYP0bnO8FBNcj6aX7CpdZvjZxCaAPfoyS647xmisq0jnUYJYzbO BsNhTlE1lYwhE1KErXUusU0q1Yx65/WoAyThkg1naVz4Le8UXIt1BGMEh0c96bx3X2vF 1lLW/J1Vf55yYRzsdZ+m2h93vaP0qXKBVPS+hbETl29CWuSm3npF8n2NMNDw2m28Tukz /XYFf69W2jeGlESgt9MJAYPfMBjz0uCWg+++ochuEcg3DFRx+N80etwdWjSLLlNWWyxi IxHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694273724; x=1694878524; 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=zGfImGE2i0Oa/11mM60HNUIqRHTuhK49A+miOddTXek=; b=lM82VSShNWTGActa0S+0+Pcl9XK60NntQ8xBm+QWwjx0o5seqYzovm7R/3W1U6NREI H0KLsCe3hXDhmlmGNUyVewUnBGFkzUAtogNTMK8wgw8H57v9XC53X5iD/DD1FciJHVcf tZOG6it1Dus7YxGiBEqStrx9bQOLZa/HpkkfQw1X7YHwE/9DWvhtdZay4hmw7oUshqZl 4wIK/Ak64Jqv2DSicrCSwqpVTzzm11uyB4a/Pv60E6ZKYs50/g76TCDvi9Y7okrQODW4 QHe0NMAhIUp0NFq8zckqO2O7QdVhLe3Tpa4BjMK00skMtEW3RQuj/TM3IW0uE74bF49X M/NA== X-Gm-Message-State: AOJu0YykOYputJW7ezEwoXnpzhNiW6wl/JfyKzv3iqNjLiiTK2n0473j UjKElVCkmKRhe77ATLYmrTR6pAgiGPQ= X-Google-Smtp-Source: AGHT+IGiGtN94AMttN0mrMqdFfCi7f4elFfhKEMIKwhpn+9h0CKKyamQ1SJD3ykz4n/X56dsur74vA== X-Received: by 2002:a7b:c4c5:0:b0:3fe:db1b:8c39 with SMTP id g5-20020a7bc4c5000000b003fedb1b8c39mr4821207wmk.41.1694273723593; Sat, 09 Sep 2023 08:35:23 -0700 (PDT) Received: from caladan ([31.177.119.112]) by smtp.gmail.com with ESMTPSA id p7-20020a1c7407000000b003fe23b10fdfsm8124873wmc.36.2023.09.09.08.35.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 Sep 2023 08:35:23 -0700 (PDT) From: Helmut Eller To: Eli Zaretskii Subject: Re: bug#65837: 30.0.50; Debugger in non-main threads In-Reply-To: <83bkebvbsj.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 Sep 2023 14:14:20 +0300") References: <83bkebvbsj.fsf@gnu.org> Date: Sat, 09 Sep 2023 17:35:22 +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: 65837 Cc: 65837@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 (-) On Sat, Sep 09 2023, Eli Zaretskii wrote: > AFAIR, it is not trivial to improve > the thread error handling significantly, but patches are welcome, of > course. Is there a design/plan for how recursive-edit is supposed to work in non-main threads? E.g. some options that come to mind: 1) It should be allowed without restriction (what currently seems to be happening). 2) There should be some locking/multiplexing scheme so that only some "foreground thread" is allowed to read events from the keyboard. 3) Only the main thread is allowed to call recursive-edit; all other threads have to communicate with the main thread in some way. (Maybe there should be one thread per terminal that runs a command loop, but that's an exotic detail.) Helmut From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 09 11:58:02 2023 Received: (at 65837) by debbugs.gnu.org; 9 Sep 2023 15:58:02 +0000 Received: from localhost ([127.0.0.1]:48345 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qf0LR-0000MB-GV for submit@debbugs.gnu.org; Sat, 09 Sep 2023 11:58:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52888) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qf0LP-0000Ls-DU for 65837@debbugs.gnu.org; Sat, 09 Sep 2023 11:57:59 -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 1qf0LH-0003Wa-6V; Sat, 09 Sep 2023 11:57:51 -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=zllJVI5MdLG1qm7AMClOWN+7bp5noG9XxKxPORgslEw=; b=A6cVuTBEalz9 EKIeSvJn8i55oVVEII5U3xHOTvR+RK0IcFStDtV1aPoplf0Bzf2l4tfYk8BHJI3WKQ0TbuICbTfYp CyqB3SHXadNxFe9v7/XlrEtR5GmKlvUZtmogGuNf53/yhe8M+x8P+A/XhZmSvvDRvy2bKKEn0evbB BfhoyiuZK6O55wtEPaXoSD+h20ewSti+KhRumj6KewWFRB703Ur4e2ULOEgmNcq9gjm3s+AO8q5Fl Zbqjo4pgpoIMJZX69fF1ue2tB0oR50be3ORTrjdFZveYCKAaQ8bbazzjKKgf/8vLuZF/5Cvk1K0+4 46CbDtbShtNdejr1qxJPLw==; Date: Sat, 09 Sep 2023 18:57:44 +0300 Message-Id: <83msxvtk3r.fsf@gnu.org> From: Eli Zaretskii To: Helmut Eller In-Reply-To: (message from Helmut Eller on Sat, 09 Sep 2023 17:35:22 +0200) Subject: Re: bug#65837: 30.0.50; Debugger in non-main threads References: <83bkebvbsj.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65837 Cc: 65837@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: 65837@debbugs.gnu.org > Date: Sat, 09 Sep 2023 17:35:22 +0200 > > On Sat, Sep 09 2023, Eli Zaretskii wrote: > > > AFAIR, it is not trivial to improve > > the thread error handling significantly, but patches are welcome, of > > course. > > Is there a design/plan for how recursive-edit is supposed to work in > non-main threads? Not that I know of, no. But you seem to be asking mainly about reading events, not about recursive-edit? > E.g. some options that come to mind: > > 1) It should be allowed without restriction (what currently seems to be > happening). Almost: the keyboard input is processed by the thread which "grabs" it. AFAIR, this is usually the main thread, but it is not enforced. > 2) There should be some locking/multiplexing scheme so that only some > "foreground thread" is allowed to read events from the keyboard. > > 3) Only the main thread is allowed to call recursive-edit; all other > threads have to communicate with the main thread in some way. (Maybe > there should be one thread per terminal that runs a command loop, but > that's an exotic detail.) User interaction when multiple threads are present is an issue we didn't figure out. I think based on past discussions it is quite clear that some kind of protocol or discipline is needed to avoid creating a terrible mess whereby the user could even completely lose the ability to interact, but it is not clear what that protocol should be and how it would work. At least the two alternatives you listed above each have problems that need to be resolved. The main issues, AFAIR, are: . if only one thread can read input, what do other threads do when they want to ask the user some question? if they should wait, then this should be somehow incorporated in the thread_select machinery . how would the user know which thread prompts him/her? (this is sometimes important) . what about just displaying messages, without any input -- should that be allowed from any thread, or should there be synchronization here as well? what about redisplay in general? This all is exacerbated by two important factors: . there's no scheduler between threads, they basically schedule themselves, so there's no entity besides the threads themselves to implement whatever protocols are needed for input multiplexing . Emacs doesn't have a separate input mechanism: input from minibuffer just reuses the normal editing and display capabilities, so whatever we do about multiple threads will directly affect these general-purpose capabilities Feel free to suggest possible solutions and ideas, just not here, on emacs-devel. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 09 12:23:44 2023 Received: (at 65837) by debbugs.gnu.org; 9 Sep 2023 16:23:44 +0000 Received: from localhost ([127.0.0.1]:48359 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qf0kK-0000y5-0F for submit@debbugs.gnu.org; Sat, 09 Sep 2023 12:23:44 -0400 Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]:50538) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qf0kF-0000xq-Js for 65837@debbugs.gnu.org; Sat, 09 Sep 2023 12:23:42 -0400 Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-31c73c21113so2788583f8f.1 for <65837@debbugs.gnu.org>; Sat, 09 Sep 2023 09:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694276611; x=1694881411; darn=debbugs.gnu.org; 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=MKiCAYbDH1W8aDiGn4DL0V2VGNBWVpgkVRy7CAAP3Eo=; b=j8rily4/dOTSxQ4QBe/ZUX/4l1FTpfrLvqL8K6WY+uxgCv+3715DKWdv+M9H+IBAd1 EK0bEgwe7CB3NZ4dS7mPNkMzRHGz0ATivYm7RVwMOsYfbXHE0CwzhvGjpOqZ4yLGcZp4 mkzJ2ns0VCLvQNX+ycFwhkltxpY0L0a/AmDBsHZUzsKQZDMsxzaTp5H1Hi9TOMWXwOQO 6flBwnLKNACx0p3SuKuJRfoj6zVjFCobTXSK2ig4CGAffirVnKTVc5g8hGRaWLL5a9sC eP6LrO1ZZ3AiNkQJzy3pzxm5jGO/KO6pah6+rKzX2/EiCigo81tfcEFXT47cqE93dcDz BZwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694276611; x=1694881411; 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=MKiCAYbDH1W8aDiGn4DL0V2VGNBWVpgkVRy7CAAP3Eo=; b=jPApK3BO1zyGBQF+yIgdOFy4kVuEBagy+C01OMJwl63ZfWS4Bbe+0IbzGNZfGgJc6u KQiG6Z3OLaCTspBvj0+ir6/3qClx4yl89zFsLnn5oOolIFWHKtZ8AnXEdWofiJXymUku wARwolWn+aIUt7Q4ksGN2Q5gR4cqcPjR0TZd4238QQUhcwSxsb1jJOxYInyPQXFzGAAT PPcH0DwzlPxm44iCz0ludPgzFwNvSdEWV/JR3TvMXKbtMS4ESxnYHg7HE/ITRLbOyV/2 s0Ir021TUJ7fu0eONxltiFhyhRykhYZmliG3jga2WL4ZhFNH2EuEdA1m1tAAzufq5ROv L47Q== X-Gm-Message-State: AOJu0YwLyYOaiC6AdW37ZxlvF0QvPklNRKxjpsQLyoZwoDp+V8xf+9bn SGl4C8Zldr76oKzjXMwB6JCeZEvjhvQ= X-Google-Smtp-Source: AGHT+IGIRCQSi0AGgo0ykhauOLQ7Ac7FGLmvsLEfr4otlfybw+wEqyk13oeBW7eKmx4ZTI0zNFF9Ow== X-Received: by 2002:adf:a3ca:0:b0:31f:84cd:90c5 with SMTP id m10-20020adfa3ca000000b0031f84cd90c5mr2500120wrb.10.1694276610410; Sat, 09 Sep 2023 09:23:30 -0700 (PDT) Received: from caladan ([31.177.119.112]) by smtp.gmail.com with ESMTPSA id l23-20020a1c7917000000b003fe17901fcdsm8224664wme.32.2023.09.09.09.23.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 Sep 2023 09:23:30 -0700 (PDT) From: Helmut Eller To: Eli Zaretskii Subject: Re: bug#65837: 30.0.50; Debugger in non-main threads In-Reply-To: <83msxvtk3r.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 Sep 2023 18:57:44 +0300") References: <83bkebvbsj.fsf@gnu.org> <83msxvtk3r.fsf@gnu.org> Date: Sat, 09 Sep 2023 18:23:29 +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: 65837 Cc: 65837@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 (-) On Sat, Sep 09 2023, Eli Zaretskii wrote: >> Is there a design/plan for how recursive-edit is supposed to work in >> non-main threads? > > Not that I know of, no. But you seem to be asking mainly about > reading events, not about recursive-edit? Well, the debugger calls recursive-edit and if it's not clear what recursive-edit is supposed to do, then replacing recursive-edit with something more reliable would be my first step to improving the debugger. Helmut From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 09 12:46:44 2023 Received: (at 65837) by debbugs.gnu.org; 9 Sep 2023 16:46:44 +0000 Received: from localhost ([127.0.0.1]:48398 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qf16a-0001Xh-7D for submit@debbugs.gnu.org; Sat, 09 Sep 2023 12:46:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38500) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qf16Y-0001XW-LB for 65837@debbugs.gnu.org; Sat, 09 Sep 2023 12:46:43 -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 1qf16Q-0003uA-Ci; Sat, 09 Sep 2023 12:46:34 -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=+BALSmnNmQpl2NuX+PDa8DRUJ9y+0q461rGnveKx6eU=; b=KR/wRxvGoHq4 623S6nadEhdF/v43lahw0XZJjVYJ9EUtnEK6DPpdetQQjY6BU9nTRz/HOYrPR01d5IljAqAbDwyKT 7diYX4XjI597fHX0vQ460P+WWYOsC/rHiU8rrejYTGQga3rdtLUxgBDT+PM00UbEQlNvu5P1Tmjxc B+zRLZaPY/9ra9GpuIbCh5fWi97UF6b0o7z3YrgwhIdvp8S82vo687lrpNs5Og4nE2c/FWE5Qp+Ex Zxp0Xo4KxikFlT58oUEu1ELyUncTU7KtYtLaNXSjVfQxUibyIsWgnHx2bacqVQXS48rPDGPh+uyU5 RqRdYYDZSbCR+Idui550cQ==; Date: Sat, 09 Sep 2023 19:46:22 +0300 Message-Id: <83il8jthup.fsf@gnu.org> From: Eli Zaretskii To: Helmut Eller In-Reply-To: (message from Helmut Eller on Sat, 09 Sep 2023 18:23:29 +0200) Subject: Re: bug#65837: 30.0.50; Debugger in non-main threads References: <83bkebvbsj.fsf@gnu.org> <83msxvtk3r.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65837 Cc: 65837@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: 65837@debbugs.gnu.org > Date: Sat, 09 Sep 2023 18:23:29 +0200 > > On Sat, Sep 09 2023, Eli Zaretskii wrote: > > >> Is there a design/plan for how recursive-edit is supposed to work in > >> non-main threads? > > > > Not that I know of, no. But you seem to be asking mainly about > > reading events, not about recursive-edit? > > Well, the debugger calls recursive-edit and if it's not clear what > recursive-edit is supposed to do, then replacing recursive-edit with > something more reliable would be my first step to improving the > debugger. If recursive-edit is run by the same thread which was running before the debugger was entered, and the debugger never calls one of the primitives that enter the idle loop (sit-for etc.), then I don't think problems will happen, because it basically means the thread which entered the debugger keeps running. But if the debugger causes its thread to yield, some other thread could grab the global lock, and then all hell will break loose. So I think the only reasonably practical way to make this particular use case stable is to disable thread switching for as long as the debugger is active. WDYT? From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 09 13:24:47 2023 Received: (at 65837) by debbugs.gnu.org; 9 Sep 2023 17:24:47 +0000 Received: from localhost ([127.0.0.1]:48430 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qf1hP-0005Al-5G for submit@debbugs.gnu.org; Sat, 09 Sep 2023 13:24:47 -0400 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]:58692) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qf1hK-0005AV-EW for 65837@debbugs.gnu.org; Sat, 09 Sep 2023 13:24:46 -0400 Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-401b393df02so35883415e9.1 for <65837@debbugs.gnu.org>; Sat, 09 Sep 2023 10:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694280273; x=1694885073; darn=debbugs.gnu.org; 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=4tPRhtbALtw5xL9H9BIz5D6ErwxIqxrrF0kOQnSzYO0=; b=LTARjTiCOrq4QzYoNJow2EbbCI9aKlYG8l/H5B4YpdVdb2VohENjBMI2qnn3ZmLmu1 +RMFYaxjVTYDdqfkzH0RsqZRRnCRZmCRUZAMkx1drZjo2RG9motD0PSNIJMO77HEnR0R KFfsRaW7FYyVOM34ThuiV9nsiPELIyPbwf8i6GOYRbNjcNdp5j15Qyidf0U/ObPE387G t6j+e1tvC/3NqU1bO760F05qdNb6bAYMLzXT5Mr1XqJ9lz2EbR2kkIFsqn9NufjwC6li 8qKrL7+7+Xomt1yuZ31Q0/wM1dY8NaTsUcRRJXti0VbaAhhqMB6Qjpu1dmJFm7+t0biI kQcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694280273; x=1694885073; 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=4tPRhtbALtw5xL9H9BIz5D6ErwxIqxrrF0kOQnSzYO0=; b=dgOp02CuILEQYRQs9ZdXVc+zUxDawFKzB1w2vrcl33wd/VjkeLMNPayiCwUYlBGrkm rjgM9O2F5tY6JFRVDF8NvZ+0HTXcQCutlE+0ExW3Suve5czqYu9C04KVgbmizSPDZgu0 LavDvEwKNXR9eqoPFKOK4QeZrcOc5NUX9lbcEaRX80m/+JvHLX1SNhvaPQQW0iOx4dm2 8DE42rjGoKGMUkzDOeSzDcIxAscTTSqEfLSZiedsoNW9b3ys+0FLqLWDrEEmIRS5bTxD 9jv41Tz+ZuIhZHGm33o4rRIk/woTX4PH+JTiVitnaqokAr6Gjf70sXYTbgu5EHild3Q3 8OnQ== X-Gm-Message-State: AOJu0YxkmNPObMmh8Z4PNYJyNAP47BdmFc3xbx+BZqU7oDRTGP8hxTGv r2OwnJcUJzFGdMP7H9LwOOfNb1laXoE= X-Google-Smtp-Source: AGHT+IEVbWQO7GZ39qjYYX9Zb1G11kVHybgZxm6LKqBq6+u9Q8aGPwM9xw0HV/u0z2oLDOTnZQtLEw== X-Received: by 2002:adf:dec2:0:b0:319:7428:9caa with SMTP id i2-20020adfdec2000000b0031974289caamr4106195wrn.38.1694280272559; Sat, 09 Sep 2023 10:24:32 -0700 (PDT) Received: from caladan ([31.177.119.112]) by smtp.gmail.com with ESMTPSA id a3-20020adfeec3000000b003196e992567sm5259751wrp.115.2023.09.09.10.24.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 Sep 2023 10:24:31 -0700 (PDT) From: Helmut Eller To: Eli Zaretskii Subject: Re: bug#65837: 30.0.50; Debugger in non-main threads In-Reply-To: <83il8jthup.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 Sep 2023 19:46:22 +0300") References: <83bkebvbsj.fsf@gnu.org> <83msxvtk3r.fsf@gnu.org> <83il8jthup.fsf@gnu.org> Date: Sat, 09 Sep 2023 19:24:31 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 65837 Cc: 65837@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 (-) --=-=-= Content-Type: text/plain On Sat, Sep 09 2023, Eli Zaretskii wrote: > So I think the only reasonably practical way to make this particular > use case stable is to disable thread switching for as long as the > debugger is active. WDYT? Having to disable thread switching for so long would be quite unfortunate. I think that is safe for the debuggee to call condition-wait or accept-process-output on a specific pipe process. That should be enough to implement some form of channel/mailbox to communicate between the debuggee and the main thread. The debuggee would then read commands from that channel and the main thread would send messages to that channel instead of executing the commands. Something like the patch in the attachment. --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=debug-patch.el --- /scratch/emacs/emacs-git/lisp/emacs-lisp/debug.el 2023-01-29 15:26:37.886911531 +0100 +++ debug.el 2023-09-09 19:20:49.039995072 +0200 @@ -283,7 +283,7 @@ (message "") ;; Make sure we unbind buffer-read-only in the right buffer. (save-excursion - (recursive-edit)))) + (debugger--recursive-edit)))) (when (and (window-live-p debugger-window) (eq (window-buffer debugger-window) debugger-buffer)) ;; Record height of debugger window. @@ -314,6 +314,24 @@ (set-match-data debugger-outer-match-data))) (setq debug-on-next-call debugger-step-after-exit) debugger-value)))) + +(require 'channel) +(defvar-local debugger--channel nil) +(defvar-local debugger--thread nil) + +(defun debugger--recursive-edit () + (setq debugger--thread (current-thread)) + (cond ((eq (current-thread) main-thread) + (recursive-edit)) + (t + (let ((ch (channel-make-channel 0))) + (setq debugger--channel (cdr ch)) + (while t + (pcase-exhaustive (channel-receive (car ch)) + ('(quit) + (message "quit received...") + (debugger-quit)))))))) + (defun debugger--print (obj &optional stream) (condition-case err @@ -755,9 +773,12 @@ (defun debugger-quit () "Quit debugging and return to the top level." (interactive) - (if (= (recursion-depth) 0) - (quit-window) - (top-level))) + (cond ((eq (current-thread) debugger--thread) + (if (= (recursion-depth) 0) + (quit-window) + (top-level))) + (t + (channel-send debugger--channel 'quit nil)))) (defun debug--implement-debug-watch (symbol newval op where) "Conditionally call the debugger. --=-=-= Content-Type: text/plain Helmut --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 09 13:38:04 2023 Received: (at 65837) by debbugs.gnu.org; 9 Sep 2023 17:38:04 +0000 Received: from localhost ([127.0.0.1]:48441 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qf1uG-0005VC-0E for submit@debbugs.gnu.org; Sat, 09 Sep 2023 13:38:04 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44788) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qf1uD-0005Uh-Ua for 65837@debbugs.gnu.org; Sat, 09 Sep 2023 13:38:02 -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 1qf1u5-0001h9-Dl; Sat, 09 Sep 2023 13:37:53 -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=uUDZYN8GrLxraBU1apD7qtzb3Rci/fh5uaLUWfF5D+Y=; b=NOGXsK4p/L8y d8HUd19s9pUI+ILg6r48UkDN9VwqldHYIjea/eV0aHfvPw4COkaCrmVHZas/ebKafpOHq/QEadVi1 sEoh3DBTtMYE9qvYRQRkcErrxT31R9u57Duo9YGpHUd4+j9DGKXhA1kS333xW6YZA+usK/yZRPgfR kmhWlRVLgHtk3vai/TenvbeeTz0cd34IujwBrZm7PvU4hp/q5vCb22qM0fN/ZTkY1rhgxkX0dpgss tGbKEWAAER/J47RhoTFIqovpHzCWUv0a/amnvJjjRxkHAYDaSXz1uYsi7cbHibX0quxCzBdb670w1 2sbbYInPbz7mP+9fcjcr4w==; Date: Sat, 09 Sep 2023 20:37:46 +0300 Message-Id: <83cyyrtfh1.fsf@gnu.org> From: Eli Zaretskii To: Helmut Eller In-Reply-To: (message from Helmut Eller on Sat, 09 Sep 2023 19:24:31 +0200) Subject: Re: bug#65837: 30.0.50; Debugger in non-main threads References: <83bkebvbsj.fsf@gnu.org> <83msxvtk3r.fsf@gnu.org> <83il8jthup.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65837 Cc: 65837@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: 65837@debbugs.gnu.org > Date: Sat, 09 Sep 2023 19:24:31 +0200 > > On Sat, Sep 09 2023, Eli Zaretskii wrote: > > > So I think the only reasonably practical way to make this particular > > use case stable is to disable thread switching for as long as the > > debugger is active. WDYT? > > Having to disable thread switching for so long would be quite > unfortunate. But not unheard of. When you debug a program, you almost always want the other threads stopped (unless the bug you are investigating happens because of the other threads). > I think that is safe for the debuggee to call condition-wait or > accept-process-output on a specific pipe process. That should be enough > to implement some form of channel/mailbox to communicate between the > debuggee and the main thread. The debuggee would then read commands > from that channel and the main thread would send messages to that > channel instead of executing the commands. Something like the patch in > the attachment. I don't see how you could implement that in a portable way. I also don't understand how you will support all the different input event types using this "channel". And finally, you prevent the main thread from running "normally", because it is now busy serving the debuggee thread -- which seems to contradict your desire not to interfere with other threads. Preventing thread switch is definitely orders of magnitude simpler, IMO. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 09 14:29:28 2023 Received: (at 65837) by debbugs.gnu.org; 9 Sep 2023 18:29:28 +0000 Received: from localhost ([127.0.0.1]:48475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qf2i0-0006lm-DZ for submit@debbugs.gnu.org; Sat, 09 Sep 2023 14:29:28 -0400 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]:45171) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qf2hy-0006lX-95 for 65837@debbugs.gnu.org; Sat, 09 Sep 2023 14:29:27 -0400 Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-401da71b83cso34981195e9.2 for <65837@debbugs.gnu.org>; Sat, 09 Sep 2023 11:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694284157; x=1694888957; darn=debbugs.gnu.org; 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=wm1jlzYPMjFYIKbEqNcW6dAmzUBfcRdTCGMRuIkzQ8A=; b=WOgeSZCK5xvV/VuTHD6kzGkGo1Y4lwBa3UgZBo5DxMz45NbncpOENHLVsK1uRbdVDB 2wgfaRs5Tca2AnVaAD3rsJm36OnNnB/Bmh8Kh+0nuPJDg5sIgt0Tj6cgx7R7l1TxZXb3 8NVH2afHNmFaJcAapTHLa6ILDK1SHmbU8OiEbKroX9y/eVRyVb927aGZVBbX1vKeP31U XPpiytNO4PnjgxGAigpiuCet03+86HU55IaZ1ede5ZJNa4IXsKE8cf3sTZyLC/0rTJ4X zySoIrajR1ukiOy8oCrXYlqGvEYPvlkdAihyH7J+mOFelyHZx4/VcOgHp0MQyl0k1pld bO+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694284157; x=1694888957; 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=wm1jlzYPMjFYIKbEqNcW6dAmzUBfcRdTCGMRuIkzQ8A=; b=DrqqNl1WvmLBAB2OgV7i4xL3pHEsXlEqVLQF/SmOH9tQTXo20jIyi/8T+8hscYqY7Q MzDCa2Vc5GZXxlHLE3H3WBB3bw2lqU1SJqgatxbfffWJ+2D0DmIjLu8snHPWB4xtNyAY ZNek+8mcm52hGZj29TH5rGAUIiF5Bo9WUOBp48MgWVLqvNkJwINJJK438NYBSX4KjFXA RzlsPcLQ/1q3sf9iY6q5v5LDM8eXHLbjjT+fHvUFa6kUGTznm6ZZt7dN0RiuTOEdjBiB vMcqj/FCCbz5d8XONsHj0Mlvl+9RiBQwGfFdynE0MLpFVlpw2uBGy073SrcCvd3qfkXW /fOw== X-Gm-Message-State: AOJu0YyMr9hltnJXaBqBXVnO/v502WXDUM1YaoDqxVSZhaBGVzOItz4G Ty5wbMDHNM8NwUYmL81wSG6myfoq6/c= X-Google-Smtp-Source: AGHT+IHMSG0qpMaZ62OLV+QqPkXDR2DfkyKcaQXKk+RyZql2D7JRAspDdtfgD2ilGw0TvO4O1CEOJQ== X-Received: by 2002:a1c:ed08:0:b0:3fe:2a98:a24c with SMTP id l8-20020a1ced08000000b003fe2a98a24cmr4262216wmh.26.1694284156676; Sat, 09 Sep 2023 11:29:16 -0700 (PDT) Received: from caladan ([31.177.119.112]) by smtp.gmail.com with ESMTPSA id w6-20020adfe046000000b0031f82743e25sm3981328wrh.67.2023.09.09.11.29.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 Sep 2023 11:29:16 -0700 (PDT) From: Helmut Eller To: Eli Zaretskii Subject: Re: bug#65837: 30.0.50; Debugger in non-main threads In-Reply-To: <83cyyrtfh1.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 Sep 2023 20:37:46 +0300") References: <83bkebvbsj.fsf@gnu.org> <83msxvtk3r.fsf@gnu.org> <83il8jthup.fsf@gnu.org> <83cyyrtfh1.fsf@gnu.org> Date: Sat, 09 Sep 2023 20:29:15 +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: 65837 Cc: 65837@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 (-) On Sat, Sep 09 2023, Eli Zaretskii wrote: > Preventing thread switch is definitely orders of magnitude simpler, > IMO. Well, then I'll wait until you fix this bug. Helmut From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 09 14:34:29 2023 Received: (at 65837) by debbugs.gnu.org; 9 Sep 2023 18:34:29 +0000 Received: from localhost ([127.0.0.1]:48490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qf2mr-00071b-Ae for submit@debbugs.gnu.org; Sat, 09 Sep 2023 14:34:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34266) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qf2mo-000719-Tf for 65837@debbugs.gnu.org; Sat, 09 Sep 2023 14:34:27 -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 1qf2mg-0000Zd-FQ; Sat, 09 Sep 2023 14:34:18 -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=pZUT94J2m6UxQuUa8UVz437Pvt5dlBY5yt6TkgI7NSI=; b=rElA/k+VSvGV eDRpu5qrrL8uP49vJMTL9KPZlMTiIceAXKDZ6FzLyNW0qv6QA+GaI9lJK6hsZ5bazfwbu60SvoVPJ 1jlXi48YcMkPiaSFpCySiqKPCj6OserO2fJaSQMg+Zuoyj6HVsFbPg6UqODOVwUWedqNYmLd0rT1+ lPZgjcyZEwsEDw+QuqOhOptH0PYZD3aSDsrWS101WRgAc9Sqc6TFDlv0XDQrC+wdArhb8lHEtasah OkGF1A3bE1gVv96W5ZBQR7x4h2VZLxrYNYp/W8dVXWMb5LLWHkki5ylpJ/XhRuX+N1Z0LTEZjgeBI YPTqL4fcMtVGStfuh9Zaag==; Date: Sat, 09 Sep 2023 21:34:07 +0300 Message-Id: <83a5tvtcv4.fsf@gnu.org> From: Eli Zaretskii To: Helmut Eller In-Reply-To: (message from Helmut Eller on Sat, 09 Sep 2023 20:29:15 +0200) Subject: Re: bug#65837: 30.0.50; Debugger in non-main threads References: <83bkebvbsj.fsf@gnu.org> <83msxvtk3r.fsf@gnu.org> <83il8jthup.fsf@gnu.org> <83cyyrtfh1.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65837 Cc: 65837@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: 65837@debbugs.gnu.org > Date: Sat, 09 Sep 2023 20:29:15 +0200 > > On Sat, Sep 09 2023, Eli Zaretskii wrote: > > > Preventing thread switch is definitely orders of magnitude simpler, > > IMO. > > Well, then I'll wait until you fix this bug. Fair enough. Can you describe the bug, though? What exactly happens that is wrong, and how to reproduce it? From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 09 14:50:40 2023 Received: (at 65837) by debbugs.gnu.org; 9 Sep 2023 18:50:40 +0000 Received: from localhost ([127.0.0.1]:48496 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qf32V-0007bc-Ue for submit@debbugs.gnu.org; Sat, 09 Sep 2023 14:50:40 -0400 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]:47253) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qf32Q-0007bM-7A for 65837@debbugs.gnu.org; Sat, 09 Sep 2023 14:50:38 -0400 Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-31f71b25a99so2708539f8f.2 for <65837@debbugs.gnu.org>; Sat, 09 Sep 2023 11:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694285425; x=1694890225; darn=debbugs.gnu.org; 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=RvUKNBIn/pYEC2OyXoOEovCyJf14+0i5/BBvAjnhxXk=; b=kJ4rzfQWDmHOu8/e1udf0ZU/ztWBDsf/C0KxC/DrziQjopk3otDij/r28zJY5VvFp3 86ciJlIYesZpsIAn9lBiBGUgJSWQV8FncRkKgp8jT2hlkD+XT0ePb5cOlWMt5UesoWHG eUpjDFJ6SiH0pxcmZYNjs4awAPn2SKhfYdn31yas5nSfqXQoXhTuCzslt0LifOiUHY9W d5Ew8XSTm51hKQIZ+z3VpysTlmLoJFIAnrIN5hpIBVzJSdqm3CvNaRtlfOdSe6uZwD7w R7l1zo2tUAiJBdDsSH8gLT1142tkhU27VwIz+9x3+uW3WmcRMEL36JQjFF/xEDetq/3t kSyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694285425; x=1694890225; 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=RvUKNBIn/pYEC2OyXoOEovCyJf14+0i5/BBvAjnhxXk=; b=upG1yfcmy/RzFSvXiQkU4MesBPYqMPjwrjRaEMY+gzigaya1UpWtZ7EsSoQBkMnWcX KEak927tIxSO8C9t2pkBMcYj/TQT5jgIg8d6Nxljv9ou1lZequ7U59JC4G37do4vUXXs NuFqxx2ssGVCBpUQ+05MO6XdrrydCi5QS4tF63lu40o5sRuHHOh86INhHoC7D51Dmbhr ScTCVnaINELetJoEGDfWqxmaMp4DLO/MGgijN6R43g0VFKKUqtaIv8daFO42A21jNGDL ISVLkFnZZICvqVhdZ0KiFWGuvMvRFLcFVU8I/NP3tgjvyhajl4qLMDyDXUwmBbRqtYLt ejYg== X-Gm-Message-State: AOJu0YwmcAU9k7kAKwxtsY4rANmHD2vbUD4avSL3hPNzaucSCahXO5n6 087J4sFcbecZC1sOzHsUZfgylGbyGYA= X-Google-Smtp-Source: AGHT+IEhgT+sRazovGlslWvCCadQtCoR+krRzWhyC6y3DthIvefmzezNmy0Qgk5gAg4ojcxrXht+xA== X-Received: by 2002:a5d:4684:0:b0:31a:dbe0:ca7d with SMTP id u4-20020a5d4684000000b0031adbe0ca7dmr4317002wrq.8.1694285425190; Sat, 09 Sep 2023 11:50:25 -0700 (PDT) Received: from caladan ([31.177.119.112]) by smtp.gmail.com with ESMTPSA id n1-20020a5d4001000000b0031435731dfasm5416290wrp.35.2023.09.09.11.50.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 Sep 2023 11:50:24 -0700 (PDT) From: Helmut Eller To: Eli Zaretskii Subject: Re: bug#65837: 30.0.50; Debugger in non-main threads In-Reply-To: <83a5tvtcv4.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 Sep 2023 21:34:07 +0300") References: <83bkebvbsj.fsf@gnu.org> <83msxvtk3r.fsf@gnu.org> <83il8jthup.fsf@gnu.org> <83cyyrtfh1.fsf@gnu.org> <83a5tvtcv4.fsf@gnu.org> Date: Sat, 09 Sep 2023 20:50:23 +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: 65837 Cc: 65837@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 (-) On Sat, Sep 09 2023, Eli Zaretskii wrote: > Can you describe the bug, though? What exactly happens that is wrong, > and how to reproduce it? Start the debugger with emacs -Q --eval '(make-thread (lambda() (debug)))' The bug is that pressing q doesn't actually delete the *Backtrace* window. The expected behavior in that the window should be deleted and the buffer should be killed. Helmut