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: Sat, 28 Dec 2024 09:36:52 +0200 Message-ID: <865xn4w963.fsf@gnu.org> References: <87o713wwsi.fsf@telefonica.net> <86ldw2zy6s.fsf@gnu.org> <867c7lw081.fsf@gnu.org> <87seq93uo7.fsf@protonmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32697"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, stefankangas@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 28 08:37:45 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 1tRROJ-0008LU-3r for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Dec 2024 08:37:43 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRRNc-0007BQ-G3; Sat, 28 Dec 2024 02:37:01 -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 1tRRNa-0007Au-3E for emacs-devel@gnu.org; Sat, 28 Dec 2024 02:36:58 -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 1tRRNZ-0000tD-8U; Sat, 28 Dec 2024 02:36:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=u/Hydi5DZsIDBTv1f7YgPmZPz9UIqMCFx/BbAr958Jw=; b=gpHbzP4NFzb8uA1xrOjE umAmK8BWt/QqJz6gciBNdAYcaPeR3ESp49molTAAqaexhQJx1K39q2G2D1YjFfKjgWSMnOGGa2j5k YqeWOelrOMSpZj3/thD3n0N0ATL1Mo/pCWfWK3KKKW/0NyDIk3AKLr9kfjgwHpas6yxly6inchL16 m1HgHf1HlqKMoJMeyaKBaXIWPKdEsFVIZA2kO9tPXUYWueMCqRkAKeUtgAnSriIih3AIe5pISqwyo l+bdKtKGOdpm4kK6KNBWzuiVwnFB5tSCgqnHGiCJPm5G4lt5sybu6gJgFdTJFl3Kmmo2SBtcHaV+u jdJ8m/4zA5jYXg==; In-Reply-To: <87seq93uo7.fsf@protonmail.com> (message from Pip Cet on Fri, 27 Dec 2024 17:26:04 +0000) 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:327237 Archived-At: > Date: Fri, 27 Dec 2024 17:26:04 +0000 > From: Pip Cet > Cc: Gerd Möllmann , stefankangas@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org > > "Eli Zaretskii" writes: > > > - Concurrent. The GC runs in its own thread. There are no explicit > > calls to start GC, and Emacs doesn't have to wait for the GC to > > complete. > > > > Pip says this is not true? > > I'm a bit confused. Right now, on scratch/igc, on GNU/Linux, for Emacs > in batch mode, it isn't technically true. This causes the signal > handler issue, which we're trying to solve. The signal handler issue is because igc can happen on our main thread as well. IOW, there are two possible triggers for igc, and one of them is concurrent. > > I also thought MPS GC runs concurrently in its own thread. > > That's what you should think: GC can strike at any time. The same is true with the old GC. > If your code assumes it can't, it's broken. I disagree. Sometimes you need to do stuff that cannot allow GC, and that's okay if we have means to prevent GC when we need that. > As far as everybody but igc.c is concerned, it's safer to assume that GC > runs on a separate thread. We are not talking about assumptions here, we are talking about facts. If igc is concurrent, it means it runs on a separate thread. If it doesn't run on a separate thread, it's not concurrent. We need to establish which is the truth, so we understand what we are dealing with. Assumptions about our application code come later.