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 10:09:25 +0000 Message-ID: <875xn0p3l1.fsf@protonmail.com> References: <799DDBC5-2C14-4476-B1E0-7BA2FE9E7901@toadstyle.org> <874j2lmd37.fsf@gmail.com> <87msgdkt29.fsf@gmail.com> <86h66lnjrt.fsf@gnu.org> <868qrxnfrw.fsf@gnu.org> <87a5ccl2zx.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="38194"; 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 Tue Dec 31 13:16:33 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 1tSbAn-0009p4-5x for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Dec 2024 13:16:33 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSb9g-0004O5-G1; Tue, 31 Dec 2024 07:15:24 -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 1tSZBw-0006tC-O6 for emacs-devel@gnu.org; Tue, 31 Dec 2024 05:09:36 -0500 Original-Received: from mail-10628.protonmail.ch ([79.135.106.28]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tSZBu-00041e-HS for emacs-devel@gnu.org; Tue, 31 Dec 2024 05:09:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735639770; x=1735898970; bh=sCJkfLnALv/zhpyumHexeu1UCdY7AQVU6QDXawvD1To=; 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=o1xvKPIBd9PFoJmYvQp2EPr2vG6dWlAMFFxkuXjHVIOaM46eP5J7tIXnCiZMKVg9V UFuKQZuwH72vBwQh/8GL4XeV65gXoS3McnIFOf6HX0lbNJ6wyRq1h/gGWogMZABfWB Hf5HglD3U0Zk7wC9+1DQvESYNeIpS2aSUrBIZA/DOH6OEm+JTdRKjqNK/HrBXcUZYR rmTipF+e/GQ5EkO4BO6M8KwFiu8x36hi2rNmvC+TJ8ihn0tcSsS9TdDr2BIt9mOvmU Uru0Rx8S3nar8yPCPDmsmxLVePseRZUk+He7Ca2PaHduvHIpaxwUpLrFc1iysmv6e4 zF1A0P/0Z/9ew== In-Reply-To: <87a5ccl2zx.fsf@gmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 115ee83b02047db9a7fd7d86026bc20f69587fb5 Received-SPF: pass client-ip=79.135.106.28; envelope-from=pipcet@protonmail.com; helo=mail-10628.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: Tue, 31 Dec 2024 07:15:16 -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:327491 Archived-At: "Helmut Eller" writes: > On Mon, Dec 30 2024, Gerd M=C3=B6llmann wrote: > >> Eli Zaretskii writes: >> >>>> From: Gerd M=C3=B6llmann >>>> Cc: Helmut Eller , pipcet@protonmail.com, >>>> spd@toadstyle.org, emacs-devel@gnu.org >>>> Date: Mon, 30 Dec 2024 19:37:38 +0100 >>>> >>>> So, to summarize, everyone agrees with Helmut? > > Except the POSIX police: it says that pthread_mutex_trylock isn't async > signal safe. I suppose this also makes it's unsafe to use MPS's fault > handler in an async signal handler. Bummer. (Does the police take > bribes?) > >>> That the SIGPROF handler in the form he described would be safe? I >>> agree. >> >> What we have in scratch/igc: > [...] >> static void >> add_sample (struct profiler_log *plog, EMACS_INT count) >> { >> #ifdef HAVE_MPS >> if (igc_busy_p ()) >> #else >> if (EQ (backtrace_top_function (), QAutomatic_GC)) /* bug#60237 */ >> #endif >> /* Special case the time-count inside GC because the hash-table >> code is not prepared to be used while the GC is running. >> More specifically it uses ASIZE at many places where it does >> not expect the ARRAY_MARK_FLAG to be set. We could try and >> harden the hash-table code, but it doesn't seem worth the >> effort. */ >> plog->gc_count =3D saturated_add (plog->gc_count, count); >> else >> record_backtrace (plog, count); >> } > [...] >> >> Now the question is if that's what Helmut was describing. > > Yes, that's what I meant. > > 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. > If the backtraces are the same, then we could record the backtrace > there; that would be much nicer. I'm still hoping for more useful backtraces. Those require looking at the C stack or global variables; I'd prefer not to make the assumption that the SIGPROF handler is interested only in some words of the specpdl If modifying MPS is fair game, we could at least eliminate the igc_busy_p () false positives, on systems nice enough to let us know which thread holds a locked mutex. On GNU/Linux, only same-thread deadlocks are detected with EDEADLK so the distinction can be made. Pip