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: igc, macOS avoiding signals Date: Thu, 02 Jan 2025 12:34:58 +0000 Message-ID: <87seq1l7ik.fsf@protonmail.com> References: <799DDBC5-2C14-4476-B1E0-7BA2FE9E7901@toadstyle.org> <87a5ccl2zx.fsf@gmail.com> <86o70sm1ts.fsf@gnu.org> <87bjwrgbky.fsf@gmail.com> <865xmznb5c.fsf@gnu.org> <86wmfdk2lx.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="3619"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Kangas , gerd.moellmann@gmail.com, eller.helmut@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 02 16:17:36 2025 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 1tTMx6-0000m1-AP for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Jan 2025 16:17:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTMva-0003bV-0z; Thu, 02 Jan 2025 10:16: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 1tTKPv-0003cM-33 for emacs-devel@gnu.org; Thu, 02 Jan 2025 07:35:11 -0500 Original-Received: from mail-4322.protonmail.ch ([185.70.43.22]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tTKPs-00069t-KM; Thu, 02 Jan 2025 07:35:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735821304; x=1736080504; bh=i81u0gIPo4o8AnS7zznhd3n8Cuq7HtiQ/vd+jYfXq6w=; 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=lYUv/zlvEVSVia8WvpgeBL136LrDI8UnBDZv78/QHc9wCmnmqVBDy5HHwK+HqtOm1 sn1BoGIYVOhm+1q1pARbjlh4WyrmNTotGdwAn9RGZZ28RyezAqh+eYAuuUCpPLBCLz 0eTeSa+qGYXnVS4kN8c2l+W9P0pwDGdDukchuuXwt5WWmZRNc81CkAvac/bLfGRzCx lQtnGmxkNQjWzaNAn0f93bxYsb0TSG5+n2OZgCKzfwnGmtgVQo8AFy72v6Wux98Gzs /DqNTu060p96dnQF3TbqmPiJJQHNX18U4yIIFWMoTUc0iMzJEb8qgMK16BwVgtn9Mc g1bJOC7nbroig== In-Reply-To: <86wmfdk2lx.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 0edce18de32aa65eb41344a4e3369074d7bba5b7 Received-SPF: pass client-ip=185.70.43.22; envelope-from=pipcet@protonmail.com; helo=mail-4322.protonmail.ch X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.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, FREEMAIL_REPLY=1, RCVD_IN_MSPIKE_H2=-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=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 02 Jan 2025 10:15:29 -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:327568 Archived-At: "Eli Zaretskii" writes: >> From: Stefan Kangas >> Date: Thu, 2 Jan 2025 02:37:12 -0600 >> Cc: eller.helmut@gmail.com, pipcet@protonmail.com, emacs-devel@gnu.org >> >> Gerd M=C3=B6llmann writes: >> >> >> Mercy: I have a lot of other Emacs-related stuff on my plate, as you >> >> are well aware. Just keeping up with this discussion is already hard >> >> for me. Please help me by reaching out to the MPS folks about this >> >> issue. >> > >> > I think it should be something "official". Maybe Stefan Kangas could >> > contact them, or Richard. >> >> I'm happy to reach out to them in official capacity, but I'm not really >> close enough to the code to be able to usefully discuss the issue with >> them. So I think it might be best to put some or all of you in Cc. >> >> Before we do anything though, are we sure that it is faster to ask them >> to do things for us, instead of, say, just sending a patch? I'm not >> sure how confident people are with hacking MPS, but if we are still >> seriously entertaining the idea of a fork then maybe we should be, to >> some extent. > > We don't know the answer, AFAIU. We could tell them that if they > prefer a patch, we can send one. I see no requirement to modify MPS, so far. The current solution should work fine for Emacs once the special-casing of fast symbol handlers, which Helmut is working on IIUC, is in place. >> If we do decide to contact them, I'm afraid that I don't have sufficient >> context to accurately describe the proposed callback. I would need to >> ask someone to summarize the idea in sufficient detail so that we can >> start a conversation. > > The problem is that evidently (at least on Posix platforms), if a > program that uses MPS runs application code from a SIGPROF or a > SIGALRM or a SIGCHLD signal handler can trigger a recursive access to > the MPS arena, Let's be specific here: it's about accessing MPS memory, not about allocating memory. In particular, we're fully aware that thread APs cannot be used from signal handlers if they're also used by the main thread. >=C2=A0which causes a fatal signal if that happens while MPS > holds the arena lock. I don't know what "fatal signal" is supposed ot mean in this case, to the MPS folks. If there is a memory barrier in place, the result will be a deadlock situation, which may or may not be detected. In the first case, there is an assertion violation, in some builds (I believe the "rash" build will simply continue and corrupt memory). In the second case, there's a user-visible deadlock. If there is no memory barrier in place (for example, while the segment in question is being scanned), but the arena lock is held, silent data corruption will occur, because we'll read an invalid intermediate state of the memory. IOW, the abort() situation is the best of three possible outcomes, not the only one we want to avoid. (I say this because I sometimes get the impression that "make the MPS arena lock recursive" is considered as a possible "solution"; it's not, for various reasons). > So we want to ask for a callback when MPS is > about to lock the arena, and another callback immediately after it > releases the lock. That's the first time I hear about the "about to lock the arena" callback. Wouldn't hurt, of course, but it's also a new idea. "Immediately", of course, may be misleading: if another thread is waiting for the lock, the lock will not be available until that thread is done with it. There's a third lock operation, of course: _trylock, used for (invasively) checking whether a mutex is currently available. Do we want a pair of callbacks for that, or a third callback, or nothing at all? > With that, we could defer the application code of > these signal handlers until after the arena is free to be accessed > again. We could block the appropriate signals before (in some cases, quite a while before) we take the arena lock and unblock them after we release it. That's not obviously the best solution, but it's the only one this change would enable, AFAICS. Running signal handler code from C without ever blocking signals at the OS level is much more complicated, and I'm not convinced it would work even with atomic types. This would also require the OS to continue guaranteeing full POSIX signal semantics while a "SIGSEGV" exception is being handled, since that involves taking the arena lock. > Alternatively, if MPS already has a solution for such applications > that use signals, we'd like to hear what they suggest. That's a useful question to ask, of course. My understanding is that MPS is configured mostly at build time, and your idea would amount to creating a replacement for lockix.c and lockw3.c which allows blocking signals. > As background, you can point them to this discussion: > > https://lists.gnu.org/archive/html/emacs-devel/2024-06/msg00568.html I think the polite thing to do would be to agree on a short but accurate summary of what it is we want, explaining why it would be helpful (it may simplify things but isn't required for correctness). Pip