Re: SIGPROF + SIGCHLD and igc

[Pip Cet]

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

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

The main thread continues to mutate Lisp data unless we stop it.  Your
proposal did not include that bit, which is hard to do on POSIX systems.

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?

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

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

Pip