From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#65837: 30.0.50; Debugger in non-main threads Date: Sat, 09 Sep 2023 18:57:44 +0300 Message-ID: <83msxvtk3r.fsf@gnu.org> References: <83bkebvbsj.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28865"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 65837@debbugs.gnu.org To: Helmut Eller Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 09 17:58:37 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qf0Lz-0007I0-Sw for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 09 Sep 2023 17:58:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qf0LT-0006EA-FE; Sat, 09 Sep 2023 11:58:03 -0400 Original-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 1qf0LQ-0006Dg-MA for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2023 11:58:00 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qf0LP-0003XG-VE for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2023 11:58:00 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qf0LS-0000MY-Pr for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2023 11:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Sep 2023 15:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65837 X-GNU-PR-Package: emacs Original-Received: via spool by 65837-submit@debbugs.gnu.org id=B65837.16942750821387 (code B ref 65837); Sat, 09 Sep 2023 15:58:02 +0000 Original-Received: (at 65837) by debbugs.gnu.org; 9 Sep 2023 15:58:02 +0000 Original-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 Original-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 Original-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==; In-Reply-To: (message from Helmut Eller on Sat, 09 Sep 2023 17:35:22 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:269879 Archived-At: > 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.