Re: SIGPROF + SIGCHLD and igc

[Eli Zaretskii]

> Date: Tue, 31 Dec 2024 13:57:09 +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:
> 
> >> > 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.
> 
> The main thread continues to mutate Lisp data unless we stop it.

This seems like a misunderstanding: I was talking about what the
signal handler does, not about what the rest of the main thread does.

What the signal handler does is under our control.

> Your
> proposal did not include that bit, which is hard to do on POSIX systems.

Which bit is that?

> But the rest of your email makes it sound like we agree we should
> improve the current code ((1) on my list), which handles signals on the
> main thread while it is suspended.  Let's do that rather than arguing?

I believe Helmut is already trying.

> > 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
> 
> ??? SIGPROF looks at the specpdl?

We already have a solution for SIGPROF, and part of it is even already
installed.

> > 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.
> 
> We already have code to switch to malloc when IGC dies.

If you run out of memory, malloc won't help much.