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: Thu, 26 Dec 2024 17:01:10 +0000 Message-ID: <87wmfm5qhq.fsf@protonmail.com> References: <87o713wwsi.fsf@telefonica.net> <87y104aih6.fsf@protonmail.com> <87ikr89gyp.fsf@protonmail.com> <87jzbn8zmu.fsf@protonmail.com> <86msgizynv.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="9658"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , =?utf-8?Q?Gerd_M=C3=B6llmann?= , ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 26 18:08:34 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 1tQrLd-0002M7-MD for ged-emacs-devel@m.gmane-mx.org; Thu, 26 Dec 2024 18:08:33 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQrLF-0007iV-Ox; Thu, 26 Dec 2024 12:08:09 -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 1tQrEj-0004SG-Db for emacs-devel@gnu.org; Thu, 26 Dec 2024 12:01:30 -0500 Original-Received: from mail-10629.protonmail.ch ([79.135.106.29]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tQrEh-0000N2-Gm; Thu, 26 Dec 2024 12:01:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735232476; x=1735491676; bh=wMMKagu7UV7yLE1lM6qLoUgvNaHLM5cz6d+iJjjBR18=; 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=hD5piY7ul8ksWHoxeAFPekYa4MJ3av9d3oFs9sp1ymOyig6XFvIaphEPLN4squaNQ oK1AuUvdSizJwhV+zZE8DN7B9JUKdGCgzlPSEKVGfjtNeFQwjyaB+qBU7GNJ3bRx/R 4YZECsHpsVJ7HU+nRDK0RCVbFqQxtwz3oQJNGvqlz78D/omZcWeHP7qdfTESJOvxmL rEtP1CHZ5AwU/2ffVGxYIOIAo24y+VVsJCe64TkyY2MU6lHB7BDEqUVWiVM8c+sG9a 4w6LTO2Ph5zvDGZXL+KAoDgw24oCWdzZ9YVocDzISJzYygxDASjjTJfwl0L24RlTPE hBXG9ZFyuy1KQ== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 6e1eaaa20ca9e1cb47697585ee3b494026c5326f Received-SPF: pass client-ip=79.135.106.29; envelope-from=pipcet@protonmail.com; helo=mail-10629.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_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 26 Dec 2024 12:08:08 -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:327163 Archived-At: "Stefan Kangas" writes: > Eli Zaretskii writes: > >>> I'm coming to all this from a completely different angle. My >>> understanding is (1) the signal handling/MPS thing, is the only thing >>> preventing landing in master >> >> That's not so. It is not the only thing we need to figure out and >> solve before we can consider landing this on master. While I think we should keep trying for a while, I still think it's possible we'll just have to conclude that the current approach is the best we can do for a quick merge. It's ugly, but the user-visible problems seem manageable. 1. Delayed signals have to wait for the next explicit check for pending signals. On GNU/Linux, we could spawn a helper thread to take the arena lock and release it again, then send a signal back to the main thread so we can check for pending signal handlers and run them, assuming we're lucky and the arena is no longer locked. This exposes quite a few MPS details, and there's a risk of an unusable Emacs if the helper thread saturates the CPU. The price we pay is that once a signal is delayed, all further signals have to go to the ping-pong thread until the main thread restores the sigmask, which it cannot do in a signal handler. 2. One flag per signal hard-codes the number of signals usable by Emacs. I don't think this is a blocker. 3. We restore the "original" sigmask, so changing the sigmask from other parts of Emacs won't work reliably. Neither will any checks for whether a signal is logically blocked, because delayed signals will be masked once in a while, causing false positives. This seems fixable, and should be fixed. >> we have unresolved issues with patches to MPS for some platforms, >> whereby we considered forking MPS or some other course of actions. > > Forking MPS is obviously better to avoid, if at all possible. Forking MPS on GNU/Linux x86-64, in particular. I'm not sure how Gerd feels about macOS. >> Also, there are several FIXMEs in igc.c itself. > > Are all of these important enough to be considered as blockers for > merging to master, or only some of them? Very few of them, I think. My impression is most of them are about the remaining places where we use ambiguous marking unnecessarily, which we should fix before concluding MPS slows us down too much, but not necessarily before we merge. (However, we should be very, very clear on that point: mps works now, but it's almost entirely unoptimized. Code which relies heavily on GC may be very slow.) Bytecode stack marking looks like a huge problem in the source code, but in reality I've never seen a crash because of it. My proposed fix is to limit the maximum stack depth of bytecode objects we read, which will turn a pernicious problem into an obvious one. And, yes, we should be careful and register all threads with MPS. This will slow down things, but I don't know by how much. That's all I can remember today, pre-grep. (Which isn't enough for me: I'd like to take the time to go through the entire diff for this). > If the latter, how about making a list of the ones that are considered > blockers, or perhaps just marking them as such in the FIXME comment in > the source code? Excellent idea. As some of the FIXMEs will go away when what is currently scratch/no-purespace is merged, maybe we should do that first. Pip