From: Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>
To: Helmut Eller <eller.helmut@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
gerd.moellmann@gmail.com, spd@toadstyle.org, emacs-devel@gnu.org
Subject: Re: igc, macOS avoiding signals
Date: Sat, 04 Jan 2025 16:02:43 +0000 [thread overview]
Message-ID: <8734hyh8kg.fsf@protonmail.com> (raw)
In-Reply-To: <87ed1iocgu.fsf@gmail.com>
"Helmut Eller" <eller.helmut@gmail.com> writes:
> On Sat, Jan 04 2025, Eli Zaretskii wrote:
>
>>> WDYT?
>>
>> I'd make these extra calls only call the SIGPROF handler if the
>> counter says some signals were missed. There's no need to affect
>> other handlers without a good reason.
>
> If I had my way, I would merge Vquit_flag and pending_signals into a
> word-sized bitset like so
Bitfield access isn't atomic even on x86_64, thus the array-of-ints in
the current code.
> union pending_signals {
> uintptr_t sigset;
> struct {
> uintptr_t quit:1;
> uintptr_t profiler:1;
> uintptr_t child:1;
> uintptr_t alarm:1;
> uintptr_t io:1;
> /* other signals */
> } s;
> } pending_signals;
>
> Then maybe_quit and process_pending_signals would be merged into a
> single function that look like this:
>
> void
> process_pending_signals (void)
> {
> union pending_signals signals = pending_signals;
> if (signals.sigset)
> {
> pending_signals.sigset = 0;
This is really
union pending_signals new_pending_signals = pending_signals;
new_pending_signals.sigset = 0; <--- HERE
pending_signals = new_pending_signals;
If a signal handler strikes at the marked location, and sets a bit, then
that bit will be unconditionally cleared by the last line.
> If no signal is pending, this only needs to load and test one word
> instead of two. If only one signal is pending, then it only calls that
I agree we should set pending_signals when we set Vquit_flag (and merge
global_igc->signals_pending and the existing flag), and simplify
maybe_quit that way, but that is an optimization only.
If you want to access individual bits atomically, you need to use an
atomic type, and have a workaround for machines without lock-free
atomics.
> handler. For the rest, I'd hope that a modern branch predictor
> determines quite accurately which handler will mostly likely be called.
Sounds like PGO, which we can do as soon as we have a representative
simulated work run.
Pip
next prev parent reply other threads:[~2025-01-04 16:02 UTC|newest]
Thread overview: 133+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-28 13:24 igc, macOS avoiding signals Sean Devlin
2024-12-28 13:28 ` Gerd Möllmann
2024-12-28 14:31 ` Eli Zaretskii
2024-12-28 14:45 ` Gerd Möllmann
2024-12-30 7:13 ` Gerd Möllmann
2024-12-30 7:23 ` Gerd Möllmann
2024-12-30 7:39 ` Helmut Eller
2024-12-30 7:51 ` Gerd Möllmann
2024-12-30 8:02 ` Helmut Eller
2024-12-30 8:47 ` Gerd Möllmann
2024-12-30 9:29 ` Helmut Eller
2024-12-30 9:47 ` Helmut Eller
2024-12-30 11:54 ` Gerd Möllmann
2024-12-30 10:05 ` Gerd Möllmann
2024-12-30 10:27 ` Helmut Eller
2024-12-30 11:53 ` Gerd Möllmann
2024-12-30 14:54 ` Eli Zaretskii
2024-12-30 15:05 ` Gerd Möllmann
2024-12-30 15:05 ` Pip Cet via Emacs development discussions.
2024-12-30 12:32 ` Pip Cet via Emacs development discussions.
2024-12-30 14:24 ` Eli Zaretskii
2024-12-30 14:59 ` Helmut Eller
2024-12-30 15:15 ` Eli Zaretskii
2024-12-30 15:24 ` Helmut Eller
2024-12-30 15:25 ` Pip Cet via Emacs development discussions.
2024-12-30 15:34 ` Gerd Möllmann
2024-12-30 19:02 ` Helmut Eller
2024-12-30 20:03 ` Pip Cet via Emacs development discussions.
2024-12-30 15:30 ` Gerd Möllmann
2024-12-30 16:57 ` Helmut Eller
2024-12-30 17:41 ` Gerd Möllmann
2024-12-30 17:49 ` Pip Cet via Emacs development discussions.
2024-12-30 18:33 ` Helmut Eller
2024-12-30 17:49 ` Eli Zaretskii
2024-12-30 18:37 ` Gerd Möllmann
2024-12-30 19:15 ` Eli Zaretskii
2024-12-30 19:55 ` Gerd Möllmann
2024-12-31 7:34 ` Helmut Eller
2024-12-31 9:19 ` Gerd Möllmann
2024-12-31 9:51 ` Helmut Eller
2024-12-31 10:00 ` Gerd Möllmann
2024-12-31 13:49 ` Pip Cet via Emacs development discussions.
2024-12-31 14:13 ` Eli Zaretskii
2024-12-31 9:51 ` Gerd Möllmann
2024-12-31 13:18 ` Eli Zaretskii
2024-12-31 14:15 ` Gerd Möllmann
2024-12-31 14:27 ` Eli Zaretskii
2024-12-31 15:05 ` Gerd Möllmann
2024-12-31 15:14 ` Eli Zaretskii
2024-12-31 15:20 ` Gerd Möllmann
2024-12-31 15:12 ` Helmut Eller
2024-12-31 15:31 ` Gerd Möllmann
2024-12-31 15:37 ` Helmut Eller
2024-12-31 15:39 ` Gerd Möllmann
2024-12-31 10:09 ` Pip Cet via Emacs development discussions.
2024-12-31 13:27 ` Eli Zaretskii
2024-12-31 14:29 ` Pip Cet via Emacs development discussions.
2024-12-31 14:34 ` Eli Zaretskii
2024-12-31 15:08 ` Gerd Möllmann
2025-01-03 18:37 ` Helmut Eller
2025-01-03 19:55 ` Eli Zaretskii
2025-01-03 20:28 ` Pip Cet via Emacs development discussions.
2025-01-04 7:01 ` Gerd Möllmann
2025-01-04 8:02 ` Gerd Möllmann
2025-01-04 8:34 ` Eli Zaretskii
2025-01-04 9:02 ` Gerd Möllmann
2025-01-04 9:59 ` Eli Zaretskii
2025-01-04 10:22 ` Gerd Möllmann
2025-01-04 13:59 ` Helmut Eller
2025-01-04 14:15 ` Gerd Möllmann
2025-01-04 14:17 ` Eli Zaretskii
2025-01-04 14:55 ` Helmut Eller
2025-01-04 15:06 ` Eli Zaretskii
2025-01-04 16:02 ` Pip Cet via Emacs development discussions. [this message]
2025-01-04 17:13 ` Helmut Eller
2024-12-31 15:07 ` Gerd Möllmann
2024-12-31 13:14 ` Eli Zaretskii
2024-12-31 14:19 ` Pip Cet via Emacs development discussions.
2024-12-31 14:31 ` Eli Zaretskii
2024-12-31 14:40 ` Helmut Eller
2024-12-31 14:55 ` Gerd Möllmann
2024-12-31 15:07 ` Eli Zaretskii
2024-12-31 15:13 ` Gerd Möllmann
2024-12-31 15:16 ` Helmut Eller
2025-01-02 8:37 ` Stefan Kangas
2025-01-02 9:05 ` Eli Zaretskii
2025-01-02 10:00 ` Helmut Eller
2025-01-02 12:34 ` Pip Cet via Emacs development discussions.
2025-01-02 13:08 ` Gerd Möllmann
2025-01-02 15:42 ` Eli Zaretskii
2025-01-02 17:56 ` Pip Cet via Emacs development discussions.
2024-12-30 12:42 ` Pip Cet via Emacs development discussions.
2024-12-30 13:40 ` Gerd Möllmann
2024-12-30 13:53 ` Pip Cet via Emacs development discussions.
2024-12-30 14:02 ` Gerd Möllmann
2024-12-30 14:32 ` Pip Cet via Emacs development discussions.
2024-12-30 14:52 ` Gerd Möllmann
2024-12-30 11:18 ` Pip Cet via Emacs development discussions.
2024-12-30 12:23 ` Gerd Möllmann
2024-12-30 11:11 ` Pip Cet via Emacs development discussions.
2024-12-30 12:13 ` Gerd Möllmann
2024-12-30 10:53 ` Pip Cet via Emacs development discussions.
2024-12-30 10:46 ` Pip Cet via Emacs development discussions.
2024-12-30 12:00 ` Gerd Möllmann
2024-12-30 12:07 ` Gerd Möllmann
2024-12-28 15:12 ` Pip Cet via Emacs development discussions.
2024-12-28 17:30 ` Eli Zaretskii
2024-12-28 18:40 ` Pip Cet via Emacs development discussions.
2024-12-28 18:50 ` Eli Zaretskii
2024-12-28 19:07 ` Eli Zaretskii
2024-12-28 19:20 ` Pip Cet via Emacs development discussions.
2024-12-28 19:36 ` Eli Zaretskii
2024-12-28 20:54 ` Pip Cet via Emacs development discussions.
2024-12-29 5:51 ` Eli Zaretskii
2024-12-28 19:15 ` Pip Cet via Emacs development discussions.
2024-12-28 19:30 ` Eli Zaretskii
2024-12-28 16:29 ` Pip Cet via Emacs development discussions.
2024-12-29 2:21 ` Sean Devlin
2024-12-29 12:22 ` Pip Cet via Emacs development discussions.
2024-12-29 15:01 ` Gerd Möllmann
2024-12-29 19:44 ` Pip Cet via Emacs development discussions.
2024-12-30 6:16 ` Gerd Möllmann
2024-12-30 12:51 ` Gerd Möllmann
2024-12-30 13:09 ` Pip Cet via Emacs development discussions.
2024-12-30 13:28 ` Gerd Möllmann
2024-12-30 5:24 ` Sean Devlin
2024-12-30 6:17 ` Gerd Möllmann
2024-12-30 5:23 ` Sean Devlin
-- strict thread matches above, loose matches on Subject: below --
2024-12-28 6:40 Gerd Möllmann
2024-12-28 12:49 ` Pip Cet via Emacs development discussions.
2024-12-28 12:55 ` Gerd Möllmann
2024-12-28 13:50 ` Óscar Fuentes
2024-12-29 8:02 ` Helmut Eller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8734hyh8kg.fsf@protonmail.com \
--to=emacs-devel@gnu.org \
--cc=eliz@gnu.org \
--cc=eller.helmut@gmail.com \
--cc=gerd.moellmann@gmail.com \
--cc=pipcet@protonmail.com \
--cc=spd@toadstyle.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).