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: Sat, 28 Dec 2024 19:15:26 +0000 Message-ID: <87zfkfei1z.fsf@protonmail.com> References: <799DDBC5-2C14-4476-B1E0-7BA2FE9E7901@toadstyle.org> <87ldvzg7vi.fsf@protonmail.com> <868qrzsojd.fsf@gnu.org> <87a5cffy8n.fsf@protonmail.com> <864j2nskup.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="37922"; mail-complaints-to="usenet@ciao.gmane.io" Cc: spd@toadstyle.org, gerd.moellmann@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 28 20:27:45 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 1tRcTR-0009lC-EE for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Dec 2024 20:27:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRcSh-0000vn-7F; Sat, 28 Dec 2024 14:26:59 -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 1tRcHg-0008Av-1H for emacs-devel@gnu.org; Sat, 28 Dec 2024 14:15:36 -0500 Original-Received: from mail-40131.protonmail.ch ([185.70.40.131]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tRcHe-0000WK-6O for emacs-devel@gnu.org; Sat, 28 Dec 2024 14:15:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735413330; x=1735672530; bh=MvAx03aZXdsnFHUx2+K26sp5XYvGcTZ7TsqX0WyjXpM=; 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=Lulw9y9JYWw0FSy6lRor5OBgiOJbEFGMn3Ifcdyc9RNRhyWTKK/K3t/D+Un8lqCpz RuyTLUU3r/hKpM7FHbmKbUVQjzQTmxwpY1JKs1WOJpDNRjOLx8RX9iJoyZ7d+WO2wA HCKbx5LthgsvxE4m8iXHPAIItUlSP8weoKW0USzugR0sxxGpoX0e1NVUVohtrjKyBg YZgeyWwgyrQjuDiJR8xDR9plkCvyZfZnUSlwQ/a5CYQz29gaCpTOwxf1IHj1jskfVw Q+prvlLVds6pJXaeLJjW8i1fehvJ11hMJ41SIgG2O4FDcH0Vu2MzBmoJ946oybKPaz yf07ZUjlyYgrg== In-Reply-To: <864j2nskup.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: d82003f1f53ce8175fab2cbcd1258d6164f42476 Received-SPF: pass client-ip=185.70.40.131; envelope-from=pipcet@protonmail.com; helo=mail-40131.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_H2=-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 14:26:54 -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:327291 Archived-At: "Eli Zaretskii" writes: > Ah, okay. I note that if we'd block signals when calling MPS and > unblock on exit, then these delays couldn't have happened, AFAIU. We can't do so for SIGSEGV calling into MPS, so this wouldn't fix all cases. Blocking signals around mps_alloc slows down (make-list 1000000 nil) by a factor of about 5 (on current GNU/Linux; possibly significantly more on other operating systems). But, yes, if we're willing to give up on unmodified MPS, blocking signals in the slow path only might work. We'd need to check finalizable objects, though, because we need to call into MPS for every finalizable object. That's a problem this approach shares with the allocation thread approach, by the way. In both cases, registering objects for finalization doesn't need to happen at allocation time: if we save a reference to the object somewhere MPS sees it, the objects won't be collected, so they won't be finalized. Pip