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 12:32:31 +0000 Message-ID: <874j2l1hei.fsf@protonmail.com> References: <799DDBC5-2C14-4476-B1E0-7BA2FE9E7901@toadstyle.org> <87h66loc17.fsf@gmail.com> <878qrxoayj.fsf@gmail.com> <8734i5o6wc.fsf@gmail.com> <87cyh9mpn5.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="12364"; 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 13:42:30 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 1tSF6L-00034G-Um for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Dec 2024 13:42:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSF5m-0002A3-Lu; Mon, 30 Dec 2024 07:41:55 -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 1tSEws-0000eH-50 for emacs-devel@gnu.org; Mon, 30 Dec 2024 07:32:44 -0500 Original-Received: from mail-10631.protonmail.ch ([79.135.106.31]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tSEwq-0006CQ-5o for emacs-devel@gnu.org; Mon, 30 Dec 2024 07:32:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735561955; x=1735821155; bh=x5vIKjXk36xpLF4FOd1mVqoN5jj5FstBsu0eVNFspCQ=; 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=Hg/6rmpeUW8TXN4ySt2lVap1v9Ym/EyP8NSuNRYhUCZITJRvztrKvE9JRVdtOVfKi IJlK6M9x2P36MhEVt7n2ETtGGspmLRuHezsUD+BwTXnPnnE+2FjFBp3SYXVnDrWY3/ I3SZrEE38Gyrp1s8Gz1a4eO52wrQjCaKsChwufq/Ja6Dyp7g2hDI7EDxEfdjw1gbLx wKP2DjeYvXM2g/8JJIwBS92RXq3EW2XHOpehL1XrxfK4V8MPtQ9MawX1WtkHFdTduU RLUcqrNx0rldOadjpzgVBxz1PvHa5pm80MuklYeqh8VWgaOHvzM0AgTK6GXzQBXtg3 uGk4FdYOgUTBw== In-Reply-To: <87cyh9mpn5.fsf@gmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: a061ef65557ae7a71e1242ff5d7dfd3237034196 Received-SPF: pass client-ip=79.135.106.31; envelope-from=pipcet@protonmail.com; helo=mail-10631.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_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 07:41:47 -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:327416 Archived-At: "Helmut Eller" writes: >> I find that difficult to understand. But it may be just a >> statistical phenomenon. Maybe filling up an APs memory is so fast so >> that the probability of a signal hitting while owning the mutex is close >> to zero, or something. > > 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. And, anyway, there's no reason for the "supposedly": we know MPS can't possibly deal with the situation because we've seen the code, so we should fix it rather than ignoring it because it's rare in typical usage. If there's any evidence this cannot happen, I haven't seen it. GC code in general contains many rarely-exercised code paths. This is no exception. Pip