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 21:20:53 +0200 Message-ID: <86r05qpa7e.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22528"; 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 20:21:26 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 1tRyqs-0005je-8y for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Dec 2024 20:21:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRyqU-0006L3-TL; Sun, 29 Dec 2024 14:21:02 -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 1tRyqR-0006Ko-01 for emacs-devel@gnu.org; Sun, 29 Dec 2024 14:20:59 -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 1tRyqQ-0001l6-8t; Sun, 29 Dec 2024 14:20:58 -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=nKyrKgjORBH39ySMThV3l60sjNiuhpFZg+n/T5Q/9OU=; b=fDgOSSScHM+v 5iBQ1Zo7Houcd3iusRgPbQoqUBx0fZjHitoAcwXriAsL6tS1wStbldLJ9eRSmihR3RE7EbTqZT+vx QHoix4gbrqgw+LrrrY4RagCfwkhkzpLPg0u4CDIsxBvhHXOIdKgKjJ4wv4ZjoXnTdk1QjOGbfJk0i dUsMIMiWFSwcWqYn+XfOd5XdURQh6N3P0tweJGweeXE3e8PSJFmHaJDUU4jv6UDwN8y6h6uhP2/uW eNUq+wpD1N702LUiLPz+v9Nq9Jtnhr3lsU+dDQuH4v0i1ORhSCr6x1Y8A3LKguEQm6xb+KnC5esI7 jaf+TsGVMNm1GKZudq6pRA==; In-Reply-To: <108c9575-f07b-41af-9626-3622d16e4cf5@cs.ucla.edu> (message from Paul Eggert on Sun, 29 Dec 2024 11:09:47 -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:327362 Archived-At: > Date: Sun, 29 Dec 2024 11:09:47 -0800 > Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, pipcet@protonmail.com, > emacs-devel@gnu.org > From: Paul Eggert > > On 12/28/24 21:47, Eli Zaretskii wrote: > > Yes, that's the purpose of the global lock: a Lisp thread can only run > > if it acquires the lock. > > OS signals are therefore ignored if a non-main Lisp thread is buggy and > holds that global lock indefinitely. I assume this is the expected > fallout from such a bug. "Ignored" in what sense? AFAIU, we've just established that a signal delivered to the main thread will cause the signal handler to run, and after the handler returns, the main thread will return to waiting for the lock. Is that what you mean by "ignored"? If so, why is this "ignoring"? And yes, 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.