From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Some experience with the igc branch Date: Sat, 28 Dec 2024 12:35:09 +0000 Message-ID: <87wmfkm1fg.fsf@protonmail.com> References: <87o713wwsi.fsf@telefonica.net> <867c7lw081.fsf@gnu.org> <87seq93uo7.fsf@protonmail.com> <865xn4w963.fsf@gnu.org> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14271"; 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: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 28 14:03: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 1tRWU0-0003WX-CU for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Dec 2024 14:03:56 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRWTQ-0000mz-H5; Sat, 28 Dec 2024 08:03:20 -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 1tRW2L-0004fH-GU for emacs-devel@gnu.org; Sat, 28 Dec 2024 07:35:21 -0500 Original-Received: from mail-4316.protonmail.ch ([185.70.43.16]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tRW2I-0000dV-N8; Sat, 28 Dec 2024 07:35:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735389314; x=1735648514; bh=CeT2v/OJ5pQ5MzzRQBMFfFuKzb3BDcEYRmjhcV8wK6U=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=Qet/VjlOCbOn+6GWZVh7YROg86WVvAD9/E4sQRms1+wVOhAUqtpTV9XRK809fCnT/ YU70cr1bSLHDx4+Z8YRcW6P78KEsWktrFBjnpXl8/2qJlW1CeUNwM/N85w6C//eTbo ZakJrLUPFlNAT7bh8/y9p0vpJJbhN+iXjK0gSE0sNYxkUPsjG66zXchAKl/l9vUUX5 AtnQIhso+V9ZC1xvwG/HJmpwLMHHBCa10xBNvXyuE2DB1Cboku3I2AwUKltx19Vxgq RF9Ov48mvbkQ4HsOOSpQrFkJOT716qlXhtyLUanDXB06t1M5FRIb51UmlFBbiGq4Tt apSHcw5JW3ieg== In-Reply-To: <865xn4w963.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: d641cc27cad86ffec4d0b85466428df9b932145a Received-SPF: pass client-ip=185.70.43.16; envelope-from=pipcet@protonmail.com; helo=mail-4316.protonmail.ch 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sat, 28 Dec 2024 08:03:16 -0500 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:327260 Archived-At: "Eli Zaretskii" writes: >> Date: Fri, 27 Dec 2024 17:26:04 +0000 >> From: Pip Cet >> Cc: Gerd M=C3=B6llmann , stefankangas@gmail.co= m, ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gn= u.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 Yes. > as well. It always happens on the main thread if that's all we've got. Even macOS emulated SIGSEGV suspends the main thread while the message is being handled, then resumes it afterwards. > IOW, there are two possible triggers for igc, Three, if you count the idle work. > and one of them is concurrent. I'd prefer to avoid that word. There are facts we need to establish, and "concurrent" isn't well-defined enough to be helpful here. On single-threaded batch-mode GNU/Linux Emacs, on scratch/igc, no second thread is created for MPS. My understanding is this is a useful, common, and intentional scenario for running MPS, not a bug or an accident. Of course we're free to change that, and run MPS from another thread, but that's not a no-brainer. >> > 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. The old GC emphatically could not "strike at any time". There is plenty of code that assumes it doesn't strike. Some of it might even be correct. >> 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. So now you're saying it's okay for code to assume GC can't strike, after agreeing a few lines up that it's not okay for code to do so. Which one is it? >> 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. The fact is we don't even know whether GC is usually on a "separate" thread on macOS and Windows. On GNU/Linux, assuming it does leads to bugs. > 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. Those two statements are equivalent. They're not sufficient to define "concurrent"-as-Eli-understands-it, just for establishing a necessary condition for that. If we agree on that condition, then no, MPS is not always concurrent-as-Eli-understands-it. > We need to establish which is the truth, so we understand what we are > dealing with. Why? Whatever the truth is, we can safely assume it's an implementation detail and not rely on it. We don't need to agree on a definition of concurrency. We don't need to agree on what's likely, just that single-thread operation of MPS and parallel MPS threads are both possible and not bugs. Pip