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: Mon, 30 Dec 2024 15:25:13 +0000 Message-ID: <874j2lyz1c.fsf@protonmail.com> References: <799DDBC5-2C14-4476-B1E0-7BA2FE9E7901@toadstyle.org> <878qrxoayj.fsf@gmail.com> <8734i5o6wc.fsf@gmail.com> <87cyh9mpn5.fsf@gmail.com> <874j2l1hei.fsf@protonmail.com> <874j2lmd37.fsf@gmail.com> 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="22806"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= , Eli Zaretskii , spd@toadstyle.org, emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 30 16:27:24 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 1tSHfv-0005lF-RS for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Dec 2024 16:27:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSHfZ-0004Lo-Sh; Mon, 30 Dec 2024 10:27:03 -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 1tSHdw-0002LL-Jc for emacs-devel@gnu.org; Mon, 30 Dec 2024 10:25:20 -0500 Original-Received: from mail-40134.protonmail.ch ([185.70.40.134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tSHdu-0001fD-AS; Mon, 30 Dec 2024 10:25:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735572315; x=1735831515; bh=BGQAFiHGjZJXyIHk2JaW5tZhT9A+gubLOBgQeWwhOzg=; 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=K6vLqnk1hFa0ApDKwa+uhWZrSdpIUReUFoGTKh5qpaM/FVif/q9Ua6Y5tFv1Mm4WR IUIwpuYTR5MzMrYffkAtJhJ6lQuIulZC2zGIu+PNxHfxyyjaml/rYh+jppgy3LzI38 xp/sfsd90ndrdn107u2tNpVjQOQI6DnZVRWNjxFiJ9IuhhwQyjRI2QRx7I2JtcHp8S UKpq27GgJ1j/ywhOYYI4yx269470yUmihFzwzf2RSb6Z+apqqZsBpsW8fllVno03Bx eVlei1Cy5jhPRomzzi/agvjpkWMJZx8ic5KfHj0dpCE0MnK//uRowS9U5e//BdXttv UiTywegLAiAhQ== In-Reply-To: <874j2lmd37.fsf@gmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 866d432d9891af4770bd5b10be124485aedecd4e Received-SPF: pass client-ip=185.70.40.134; envelope-from=pipcet@protonmail.com; helo=mail-40134.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=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 30 Dec 2024 10:26:41 -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:327442 Archived-At: "Helmut Eller" writes: > On Mon, Dec 30 2024, Pip Cet wrote: > >> "Helmut Eller" writes: >>> Very few of Emacs' signal handlers actually touch a barrier. I've also >> >> Indeed. These crashes are rare in typical usage, which doesn't mean we >> should delay fixing them until Emacs is "unstable enough". It already >> is, IMHO, because we take that approach too frequently. >> >>> not seen any reproducable receipes for the "signal issues" that the igc >>> branch supposedly has. >> >> Removing the SIGPROF protection code should allow Ihor's recipe to crash >> again. > > Talking about SIGPROF protection code. It appears to me now (again) > that, for the SIGPROF handler, this pseudo code > > if (mps_arena_busy ()) > plog->gc_count =3D saturated_add (plog->gc_count, count); > else > record_backtrace (plog, count); > > is safe. Yes, it's safe, because it does have protection code. The question was the extent to which this protection code is required, and whether we can find another way to deliver signals which doesn't require it. IMHO, we now have three solutions that are still in the running (my order of preference): 1. keep the current code and special-case some signals which are needed for user responsiveness 2. use the signal serialization thread you proposed 3. use an allocation thread, but keep SIGSEGV on the main thread The first two can be combined with blocking other signals in the SIGSEGV handler (which would make all platforms behave the same and avoid SIGSEGV-handler-SIGSEGV races). The third requires it. I'd like to take (3) out of the picture for now. It's working here (still forwarding SIGSEGV, but that's not the point), and performance seems okay (better, for some unknown reason; maybe it's just chunk size), but I couldn't make it behave reproducibly when run under rr, and it makes a "GC is rare" assumption when it splits MPS objects. I'd like to be able to use rr, and "rare GC" assumptions mean that further improvements to or even fine-tuning of MPS would have to happen differently. IOW, MPS needs hacking to make an allocation thread truly viable, mostly to distinguish fast-path and slow-path allocations. Not a major change, I hope, but also out of scope for getting things to work with upstream MPS, which remains my goal. I think improving (1) is most likely to do that (but that would require a shadow signal mask, most likely). > If we don't hold the lock, then mps_arena_busy returns false > and we can access memory. We are safe even if another thread has > claimed the lock by the time that we reach record_backtrace: the SIGPROF > handler will just block until the lock is released. > > Does somebody disagree? Not me. Pip