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: Tue, 31 Dec 2024 14:29:18 +0000 Message-ID: <87cyh8nczh.fsf@protonmail.com> References: <799DDBC5-2C14-4476-B1E0-7BA2FE9E7901@toadstyle.org> <87msgdkt29.fsf@gmail.com> <86h66lnjrt.fsf@gnu.org> <868qrxnfrw.fsf@gnu.org> <87a5ccl2zx.fsf@gmail.com> <875xn0p3l1.fsf@protonmail.com> <86ldvwm190.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="35613"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, spd@toadstyle.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 31 16:05: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 1tSdoX-00097M-Fj for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Dec 2024 16:05:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSdns-00028y-Bd; Tue, 31 Dec 2024 10:05:05 -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 1tSdFN-00043L-Pc for emacs-devel@gnu.org; Tue, 31 Dec 2024 09:29:26 -0500 Original-Received: from mail-40133.protonmail.ch ([185.70.40.133]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tSdFM-0004AV-4e; Tue, 31 Dec 2024 09:29:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735655361; x=1735914561; bh=sCV8x2bo/Vc8A7q4LMpkScVtNWfLCjB6llSqe3V4qEk=; 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=ixn34moiV0qCjRX8jVQ3Et6r8PP6m6ACtGaLr77Q5+mAOeblUp+1lX7SPM2rptv6l DT5IAfgM9YFdfzVyozJxJnzQxN5rp0QwbV2NcfYvKdiYOxbQLg+n3gMw3nZGXeUMOh DsC6l/BGneuRS0mVuCBQV1JHZdPEinuLSmSh0nsIvjqcShyqfGpw5OFG8fsmY++lIP pQQSmCvNUdx+b5nqhCTakRGrbdGfhkFAUv8WVAUpPtAmalD610Oj3dzNm6SLnR97RT V0lcjhcWPscBA2kEpXrJdKW/NI8+uE4UZbE+XHUpYqfR6P37GsOWyh3ncOLA//BGuE rZ34b5O5VZPTA== In-Reply-To: <86ldvwm190.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: f939083bd97550caf5d6b184180551aff37a113d Received-SPF: pass client-ip=185.70.40.133; envelope-from=pipcet@protonmail.com; helo=mail-40133.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: Tue, 31 Dec 2024 10:05:01 -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:327519 Archived-At: "Eli Zaretskii" writes: >> Date: Tue, 31 Dec 2024 10:09:25 +0000 >> From: Pip Cet >> Cc: Gerd M=C3=B6llmann , Eli Zaretskii , spd@toadstyle.org, emacs-devel@gnu.org >> >> "Helmut Eller" writes: >> >> > I wonder if the backtrace that we see in the signal handler is any >> > different from the backrace that we would see at the next safe point >> > (i.e. the next time maybe_quit is called). >> >> If we keep a shadow signal mask, the only requirement for a safe point >> is that we made some progress OR the lock was released. But the >> backtrace will change if we wait for the next maybe_quit, IIUC. >> >> maybe_quit is not a great safe point, it's just the best we have. It's >> insufficient if Emacs becomes idle, and how often we call rarely_quit >> is quite unpredictable. > > What about doing that from process_pending_signals? Yes. The rest of this email is a half-hearted defense of why I didn't do that right away. We certainly want to call it from unblock_to if the count reaches (I think that's what you meant?), but I wasn't convinced we wouldn't need a shadow signal mask for that. Merging the pending_signals flag in keyboard.c and the one in igc.c (if that's what you meant) sounds like a good idea, too, but needs some more thought: if we handle some signals while input is blocked, but not others, what should pending_signals be? Anyway, I'm perfectly willing to give up on the "no shadow mask" assumption. Maybe it'll help us catch some signal bugs on weird platforms if we use it when --enable-checking --with-mps=3Dno. Pip