Re: SIGPROF + SIGCHLD and igc

[Pip Cet]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Date: Mon, 30 Dec 2024 16:46:20 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, ofv@wanadoo.es, 
>> emacs-devel@gnu.org, acorallo@gnu.org
>>
>> We can't avoid re-killing because we might be on another thread.
>
> If we are on another thread, we know that, and can delay running the
> body.  Or we could just run the body (all the signal handlers we have
> that I know about don't care: MS-Windows already does that).  So this
> problem doesn't exist in practice, IME.

Your (second) suggestion was to run the "signal handler" in parallel to
the main thread, which continues to mutate Lisp data.  I'm pretty sure
we don't do that on Windows (where we make use of the non-POSIX feature
of suspending threads, I hope); if we do, it'll cause weird crashes.
Half-written EMACS_UINTs are the least of our problems there: if SIGPROF
doesn't freeze the specpdl, it will read dangerously incorrect data.

I don't think this approach works for any signal that we can't simply
special-case in our current code.  Throwing overboard working code
(which, yes, can be improved.  Correctness first, though) to install a
solution that we know cannot possibly work, but relies on modifying MPS?
No.

(I also don't think all is well with Emacs.  We need to improve its
stability, not use its existing imperfections as an argument that
reducing stability is okay.)

All that said, signals are on their way out, and have been for a while.
It's unlikely we'll see exciting new signal handlers, and very likely
that we will stop using some of the existing ones (GNU/Linux doesn't
require SIGALRM or SIGPOLL/SIGIO, since it can poll fds efficiently.
SIGSEGV is already handled differently, more like macOS does it, on some
Linux kernels used in Android systems (which is good for us); SIGCHLD
is, I think, being replaced by process fds); or, at least, simplify them
in all Emacs branches.

I'm not aware of a compelling reason to do anything but improve the
current code incrementally.  Radically different approaches have been
tried; some work, some don't, those that do work have severe
disadvantages.  In the end, it's just signals.  It's important they work
and work correctly, but if you're receiving them at high rates you
should look at non-signal solutions.

I still think we should decide whether we want a shadow signal mask
(which would allow us to check for pending signals much more often) and
whether we want to block some (most) signals while handling SIGSEGV,
reinstalling the MPS handler to do so.  I'm thinking yes to both.

I'd also like a triple-quit-like mechanism for reacting to certain
signals in the event that we get stuck in MPS (as MPS has very few
bugs, it's most likely we're actually stuck in our own code called from
MPS).  This will be important if we want people to trust the MPS branch
with their work, because it would sometimes allow recovery of such
sessions (data point: I just lost an email I was writing because I was
using the igc branch).

Pip