Re: MPS: a random backtrace while toying with gdb

[Eli Zaretskii <eliz@gnu.org>]

> 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.