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: Sat, 28 Dec 2024 21:36:55 +0200 Message-ID: <86wmfjr44o.fsf@gnu.org> References: <799DDBC5-2C14-4476-B1E0-7BA2FE9E7901@toadstyle.org> <87ldvzg7vi.fsf@protonmail.com> <868qrzsojd.fsf@gnu.org> <87a5cffy8n.fsf@protonmail.com> <864j2nskup.fsf@gnu.org> <861pxrsk1z.fsf@gnu.org> <87v7v3eht9.fsf@protonmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31596"; mail-complaints-to="usenet@ciao.gmane.io" Cc: spd@toadstyle.org, gerd.moellmann@gmail.com, emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 28 20:37: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 1tRcd7-00087B-5N for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Dec 2024 20:37:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRccP-0005d5-Vb; Sat, 28 Dec 2024 14:37:01 -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 1tRccN-0005cp-KQ for emacs-devel@gnu.org; Sat, 28 Dec 2024 14:36:59 -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 1tRccL-00065y-Ux; Sat, 28 Dec 2024 14:36:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=lNAYFZcg19apk65SW5cW1lfMmJ9XGpQZUBsNrEdwidE=; b=cdBtSELngpXx MPhMvIqwzFBHQZrDElKA/W2t0AibOFJusB9azz7A07WZZfonb4INKyw1BPh09aU5blsKFwhyLcFpJ byvilklAv5ZWXXGcmdQqQEa7ORXD3dTk8Pa7+tFW1tSTV5sjPNB8v4MSUFnRKN4E6R5RQcWPWvi2w hKAt/lSIk16zLvDR47hY2bpkYj8eroAehKz2uowbeuKEM07xhQUoX5YhC/Ur0zv/T7QchhY36QCok a6FaIrh/5YvhDhavGgdWtRnERk1ypVftXkce2b8ZkhuJ4MGu1opxbBvpx1Iuj0NqDJwWyCnNa03te xAt7ZrSVdoptVreiJ/cRMw==; In-Reply-To: <87v7v3eht9.fsf@protonmail.com> (message from Pip Cet on Sat, 28 Dec 2024 19:20:40 +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:327294 Archived-At: > Date: Sat, 28 Dec 2024 19:20:40 +0000 > From: Pip Cet > Cc: spd@toadstyle.org, gerd.moellmann@gmail.com, emacs-devel@gnu.org > > "Eli Zaretskii" writes: > > > But OTOH, if this delaying of a signal affects responsiveness, then > > all we need to do is exempt SIGSEGV from being delayed, right? This > > signal-delay mechanism was invented for SIGPROF, SIGCHLD, and SIGALRM, > > but there's no reason to delay SIGSEGV. > > SIGSEGV is never delayed in any proposal I'm aware of. The call to gc_signal_handler_can_run is inside deliver_process_signal. Are you saying that deliver_process_signal is not called for SIGSEGV? > > And AFAIU, on macOS there's no SIGSEGV anyway, is that right? So why > > does this delaying affect responsiveness? > > Possibly SIGPOLL. We don't need to block SIGPOLL, either. Its handler is safe, the same as SIGIO.