[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MPS: a random backtrace while toying with gdb
From: |
Eli Zaretskii |
Subject: |
Re: MPS: a random backtrace while toying with gdb |
Date: |
Mon, 01 Jul 2024 05:33:58 +0300 |
> Date: Sun, 30 Jun 2024 19:25:36 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, gerd.moellmann@gmail.com,
> yantar92@posteo.net, emacs-devel@gnu.org
>
> As Eli points out, most of our signals don't have arguments, so how about
> simply having one flag per signal? Even a global signal flag would require us
> to block signals while we clear it.
How is this different from blocking the signals using the signal mask?
What do you think the system does when you block a signal? It does
the same. The differences are just two:
. blocking signals uses system calls, which are well-documented,
their semantics is well-understood, and their implementation is
reliable. By contrast, doing that in our own home-grown code will
definitely have windows of race conditions, and will generally be
less reliable, as any tricky signal-related code in userland;
. instead of blocking signals only around MPS calls, we will be
blocking signals for much longer times, thus making the
above-mentioned windows larger and disabling more useful Emacs
features
And that is even before we consider the fact that we have no plan for
the profiler, the SIGINT on TTY frames, and SIGUSR1/2, which are all
very useful features and their lack will be noticed.
And the only reason for not blocking signals as I suggested was
"yuck", with no further explanation. I frankly cannot see any good
sense in not liking that, but then going ahead and reimplementing the
same idea in our own code.
- Re: MPS: a random backtrace while toying with gdb, (continued)
- Re: MPS: a random backtrace while toying with gdb, Helmut Eller, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Eli Zaretskii, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Helmut Eller, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Eli Zaretskii, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Helmut Eller, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Gerd Möllmann, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Pip Cet, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Ihor Radchenko, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Eli Zaretskii, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Pip Cet, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb,
Eli Zaretskii <=
- Re: MPS: a random backtrace while toying with gdb, Eli Zaretskii, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Ihor Radchenko, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Eli Zaretskii, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Gerd Möllmann, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Gerd Möllmann, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Gerd Möllmann, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Pip Cet, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Eli Zaretskii, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Pip Cet, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Eli Zaretskii, 2024/06/30