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: igc, macOS avoiding signals Date: Thu, 02 Jan 2025 17:42:57 +0200 Message-ID: <86ldvtjk72.fsf@gnu.org> 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> <87seq1l7ik.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="30606"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefankangas@gmail.com, gerd.moellmann@gmail.com, eller.helmut@gmail.com, emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 02 16:44:25 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 1tTNN2-0007ok-UR for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Jan 2025 16:44:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTNMG-0003lq-G2; Thu, 02 Jan 2025 10:43:36 -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 1tTNME-0003lZ-Sk for emacs-devel@gnu.org; Thu, 02 Jan 2025 10:43:35 -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 1tTNME-0003Ib-Cm; Thu, 02 Jan 2025 10:43:34 -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=ZwPXIyX8TkrCS5wqeLg7IxvWY+0DqulwT4Dde9yvtpo=; b=A5HU3XnF1+/sNgf/gtAh KqNrbcxZ+oa/OOTm521vyy+cq0WNZBgY4WkKRmkfdEGnalW5HbBnRviwtIyzuEoRJsb+7T+WFLauh QaKnV07zJ1IZEOHES96iYKtK0Grbpqt21sav9yBzN6EcXfROBWcjJAT3Sidn8FYmgmGCdLu76ma4P dak7ShD4e/Wss9mnaN2gGPAJzzpdF+cyKgjdb6QFXpgwb0MrVGTZ+HqTYWuCKzeiDDrtEVx7O8q1+ fuY2ngeYyUcX7KeHndSsEg6oB45ePdprCr4utXAenL2VNhDDtq/I4d3fxoIyAsVotgHdH89Gv56K4 jp3b8zlQKSbmDA==; In-Reply-To: <87seq1l7ik.fsf@protonmail.com> (message from Pip Cet on Thu, 02 Jan 2025 12:34:58 +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:327571 Archived-At: > Date: Thu, 02 Jan 2025 12:34:58 +0000 > From: Pip Cet > Cc: Stefan Kangas , gerd.moellmann@gmail.com, eller.helmut@gmail.com, emacs-devel@gnu.org > > > 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. There's no requirement, but it would be silly, IMO, to try to solve these issues without ever talking to the MPS developers. We have nothing to lose, but it's possible that they will point out other solutions. Why give up that up front? It makes no sense to me. > 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. Another pair (or several pairs) of eyes, and by people who know more than we do about the library, cannot do any harm. We can always decide to go our way, regardless. > >> 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. I agree. But then I didn't say anything about allocations. > > which 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. It's an accepted terminology, but we could explain if needed. My text was for Stefan (who does know what "fatal signal" means), not for quoting it verbatim in a message to MPS. > > 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. It was always the 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. Which other thread? There can be only one Lisp thread running at any given time. > 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? I think these questions are ahead of time. We should first hear what the MPS developers think about this idea. > 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. The problem is, we don't know when the arena will be locked, thus the request for a callback. > > 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. Once again, let's hear what the MPS developers have to say about that. > > 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). That discussion has several backtraces which might be useful for them to better understand the issue.