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.devel Subject: Re: Some experience with the igc branch Date: Sun, 29 Dec 2024 22:01:52 +0200 Message-ID: <86o70up8b3.fsf@gnu.org> References: <87o713wwsi.fsf@telefonica.net> <87ldw6as5f.fsf@protonmail.com> <86o7112rnq.fsf@gnu.org> <867c7p2nz4.fsf@gnu.org> <861pxx2lh7.fsf@gnu.org> <86ldw40xbo.fsf@gnu.org> <86a5cj2a0e.fsf@gnu.org> <867c7n28sf.fsf@gnu.org> <877c7n962e.fsf@gmail.com> <8634ib24gp.fsf@gnu.org> <875xn75w7u.fsf@gmail.com> <86ttaryn1x.fsf@gnu.org> <877c7mzxbw.fsf@gmail.com> <861pxuzt61.fsf@gnu.org> <87wmfmy6mq.fsf@gmail.com> <86ttaqxybk.fsf@gnu.org> <867c7ly2v8.fsf@gnu.org> <86v7v4ut8w.fsf@gnu.org> <86seq7qbvu.fsf@gnu.org> <108c9575-f07b-41af-9626-3622d16e4cf5@cs.ucla.edu> <86r05qpa7e.fsf@gnu.org> <3056b6f4-1986-4fb2-b961-aa371e6016b3@cs.ucla.edu> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6414"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, pipcet@protonmail.com, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 29 21:02:56 2024 Return-path: Envelope-to: ged-emacs-devel@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 1tRzV2-0001WO-6i for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Dec 2024 21:02:56 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRzU7-0004LJ-27; Sun, 29 Dec 2024 15:01:59 -0500 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 1tRzU5-0004L2-9d for emacs-devel@gnu.org; Sun, 29 Dec 2024 15:01:57 -0500 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 1tRzU4-0005Hq-TF; Sun, 29 Dec 2024 15:01:56 -0500 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=437nkzgog/uzb1Ap5NTTr2XLpXzzMLjctEpHPOkkcIE=; b=EZ1OstkBH3CO XdXpF1swZG3MF1vu2zYdYJCbW+IBVsecq+DhOp8xxd0OVBoEx4knJ9Ls8INSR4NV23TyDlhHM9adf nzzx7gYy0GkX1ixsz+4QSY3D+ReStWuC0DkotHmz7S/tJsrRxuEuIPftVHm+kaJrLp11sFIQYDzVA O0i19Tp0KjlXsn/0WZ3zYWsq8wyLxWUoxm1AexcnGOF/qxPIw5ZhVn19tNLCJefUWwQ4YwM4ZgGpY 0p30ds+Gh5Ko20FmGTZpdxDV961ucD8tLiASktBRCUBa9Ar5zERyouQ8SRFRuOyZNpK2ojOqPYous SGuCAzTlK6URxNbtxE+CDA==; In-Reply-To: <3056b6f4-1986-4fb2-b961-aa371e6016b3@cs.ucla.edu> (message from Paul Eggert on Sun, 29 Dec 2024 11:30:22 -0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:327366 Archived-At: > Date: Sun, 29 Dec 2024 11:30:22 -0800 > Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, pipcet@protonmail.com, > emacs-devel@gnu.org > From: Paul Eggert > > On 12/29/24 11:20, Eli Zaretskii wrote: > > if a non-main thread's Lisp function keeps running forever, > > never calling any primitives that release the lock, that thread will > > run forever, and the main thread will never get a chance. Lisp > > programs that cause this are considered buggy, of course. > > > >> I don't see this issue documented explicitly in doc/elisp/threads.texi. > >> Should it be? > > I will have an opinion when I better understand what "it" is in this > > case. I hope this is just a misunderstanding. > > It's the issue summarized in your paragraph that I quoted above, along > with its consequences, which are obvious to someone who knows how Emacs > Lisp threads work but not so obvious to newcomers who may have several > notions of "threads" rattling around in their heads. > > It's not just that the main thread never gets a chance: it's that > signals are effectively ignored. If the signal handler gets invoked and does its thing, how can that be considered as "effectively ignoring" the signal? Can you describe on some concrete example how signals should work in some situation, and then how you think that is changed when a on-main Lisp thread holds the global lock, which leads you to say the signal is "ignored"? > Does the same thing happen with C-g? If so, I'd think that should also > be documented in threads.texi. C-g generates a signal only on TTY frames. Is that what you mean? And when you say "the same happens", what do you mean by that? If you somehow have the impression that C-g doesn't work when a non-main thread runs, then this impression is incorrect.