Re: SIGPROF + SIGCHLD and igc

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 30 Dec 2024 21:04:34 +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
> 
> "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

Yes.

> which continues to mutate Lisp data.

No.  Doing that from a signal handler is a definite no-no, certainly
if we call the handler from a non-Lisp thread.  The only signal
handler which currently does touch Lisp data, or comes close, is
SIGCHLD.  The MS-Windows emulation of SIGCHLD runs the handler
synchronously (it is called from the emulated pselect); for Posix
systems I believe we already have an alternative implementation on
some branch which moves the body of the handler to the main thread.

> I don't think this approach works for any signal that we can't simply
> special-case in our current code.

We only have 2 or 3 to worry about, and IMO we know enough about them
to safely say that they all can (or already are) special-cased.

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

No, of course.  But what you describe above is not the intent, at least
not what I meant, and I don't believe anyone else in this discussion
means anything like that.

> I'm not aware of a compelling reason to do anything but improve the
> current code incrementally.

I think what's being proposed (by Helmut, mainly) is a move in that
direction.

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

Maybe, but let's discuss that after we have the basics of the modified
handling of those 3 signals that will allow us to get rid of the
crashes.

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

You mean, the "emergency exit" feature?  Yes, that should be very
useful, but note that it cannot always succeed, because if you escape
from GC, anything that allocates memory is living on borrowed time.
And saving buffers generally must allocate memory.  So it is not easy
to make this reliable enough, it needs very careful programming and
probably also some small reserve of memory ready to be used.