From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: igc, macOS avoiding signals Date: Tue, 31 Dec 2024 08:34:42 +0100 Message-ID: <87a5ccl2zx.fsf@gmail.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> <874j2l1hei.fsf@protonmail.com> <874j2lmd37.fsf@gmail.com> <87msgdkt29.fsf@gmail.com> <86h66lnjrt.fsf@gnu.org> <868qrxnfrw.fsf@gnu.org> 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="40290"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , pipcet@protonmail.com, spd@toadstyle.org, emacs-devel@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 31 08:35:47 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 1tSWn3-000AI8-S3 for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Dec 2024 08:35:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSWmB-0006Ty-Qt; Tue, 31 Dec 2024 02:34:51 -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 1tSWmA-0006TK-0r for emacs-devel@gnu.org; Tue, 31 Dec 2024 02:34:50 -0500 Original-Received: from mail-ej1-x62a.google.com ([2a00:1450:4864:20::62a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tSWm8-0003TX-Dm; Tue, 31 Dec 2024 02:34:49 -0500 Original-Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-aa69107179cso1613809166b.0; Mon, 30 Dec 2024 23:34:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735630486; x=1736235286; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=XS+5AbNio4IDhPcCLwZu303FGQeskGEOAPPda+AwL1o=; b=PmOm9WQ6qDEyIP3U6ho/SWHoP3o8wowCg6z9ejvh9ELQRxdTiEde1+GDEvQNVSPuhN bCHXSVcq8aXKG9N0ijRzfLo3/UCOJ+UFWwwapoXhArW5Pzwd5ZBoZPOVSticBGFI2a8d Ed2L8qKByG3GNUEZZo0kaxBOTTj7rNOgOyaYZKeEE5hp6hPTtbRqt+/cjcdumH07hJDF VnIiGqKfqH41fqXst3WCa8YTB9dt+Rii/BwF8Xl7EmdQMH7sWym5JIsR+efLusX/tiwh SFpQ8rFIq5h7Yw2cJYjGAJa87dhEonpgyLikNL+jjF8eCn1HxtFNCuN156VpIG7EZ1R0 nc6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735630486; x=1736235286; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=XS+5AbNio4IDhPcCLwZu303FGQeskGEOAPPda+AwL1o=; b=damCIaT+T9hGOdqEGvdxCYhi7ojEWADtTRniCNwNnPxF38vTXjcsZTBMkpYpA2B7Xu nocTg9zraptMKGo89v3ClW2AkK3acqq1ftJIkUZwp0mV8IOq9uSRDI9PdnKeU9T7NHew W5E+sTB0XFThiv/Knm5T5paqozLdJxUXCPl6vBK+DiQKBpjfZWtTAt0Axj5ypt64EyMF 1hFWAF6o96mQu4zvB4q1H+rSsqZQeKh0OeewvrHowqS8W6r6GZSnunk9S+dXbf5yo9sZ 6OHbZJX7gb03MKTybyZfyjIuh49uekpdX6c00sG3qCR1BdSDud1bhjWcWftEUbp562NA XyUQ== X-Forwarded-Encrypted: i=1; AJvYcCUF6UhpcKCQadsFTcIBbB8RBy7CWGt/j6sHNglZ4oz2co1xFXIrHYfK9tupgBOKkyHGqHaPqeAooFliag==@gnu.org X-Gm-Message-State: AOJu0YzgL6pEhqFYzgsj8CVfg1h3T7bqotv4z99f2Ty78uKuT0dYdNvR NJwz9nz48hvfT2neQgZJ/XxEoSN2AJbv82n27tF0GDiEYIfEw4Aih1ou2pYT X-Gm-Gg: ASbGncvHsCeW1+bMxXltOY3Xclk3w68mCsEpeEAG7H9Tbq9NSJ1O0+AywkgrJJ9qfP3 6AZALyqfThWBkVi4UCKWb+P3cQ5Ok+WnF5Unl6G89NK0n3sCd+3CCMi4Ikj2UqJYwXARlEbiTyk cqetmd7a1fsKvpSH2Zbye0Lzr7EjuF9Q2YFJEambQuTzwgjeyiwbw6bZ4L+LFbWmPJ5uCm2ki+p I2Tlol5/ZMxuK9JS8e9IEWFkfOAu/rPtwtQ0+twcTi6lOT9Y7Ii3SU= X-Google-Smtp-Source: AGHT+IGQ4TV7j6Qp2i1CS2OZzjvCG6Xvq0PuTKVHxUtYMLB7cy/FYmRYbu1Qt9Lb4zrPMnZTG5a6ow== X-Received: by 2002:a17:907:60cf:b0:aac:1b56:324a with SMTP id a640c23a62f3a-aac2b9463f4mr2899466866b.26.1735630485423; Mon, 30 Dec 2024 23:34:45 -0800 (PST) Original-Received: from caladan ([31.177.115.143]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0e830b10sm1543154066b.37.2024.12.30.23.34.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Dec 2024 23:34:44 -0800 (PST) In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llmann=22'?= =?utf-8?Q?s?= message of "Mon, 30 Dec 2024 20:55:57 +0100") Received-SPF: pass client-ip=2a00:1450:4864:20::62a; envelope-from=eller.helmut@gmail.com; helo=mail-ej1-x62a.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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:327481 Archived-At: 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 >>>=20 >>> 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 the backtraces are the same, then we could record the backtrace there; that would be much nicer. Helmut