emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SIGPROF + SIGCHLD and igc


From: Gerd Möllmann
Subject: Re: SIGPROF + SIGCHLD and igc
Date: Wed, 25 Dec 2024 10:43:12 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Helmut Eller <eller.helmut@gmail.com> writes:

> On Tue, Dec 24 2024, Gerd Möllmann wrote:
>
> [...]
>>>> - Lisp allocation in signal handlers cannot exist because alloc.c is not
>>>>   reentrant which means we would crash with the old GC. We don't need
>>>>   anything extra for that in igc.
> [...]
>> BTW, do you agree with my analysis that Lisp allocations can't possibly
>> exist in signal handlers today?
>
> I don't know alloc.c well enough to make a judgment.  This comment for
> XMALLOC_BLOCK_INPUT_CHECK seems to say that signal handlers used to
> allocate but no longer do:
>
>   If compiled with XMALLOC_BLOCK_INPUT_CHECK, define a symbol
>   BLOCK_INPUT_IN_MEMORY_ALLOCATORS that is visible to the debugger.
>   If that variable is set, block input while in one of Emacs's memory
>   allocation functions.  There should be no need for this debugging
>   option, since signal handlers do not allocate memory, but Emacs
>   formerly allocated memory in signal handlers and this compile-time
>   option remains as a way to help debug the issue should it rear its
>   ugly head again.  */
>
> Helmut

Thanks.

Stefan Monnier seems to have added that 2012, judging from git grep in
the ChangeLogs, and it reads as if it has something to do with
SYNC_INPUT, which I think means no longer doing X event handling in a
SIGIO handler.

And it seems to be no longer in use. XMALLOC_BLOCK_INPUT_CHECK appears
nowhere, and MALLOC_BLOCK_INPUE is always a no-op. alloc.c could need
some love.

Anyway. Just looking at Fcons wrt async-signal-safety, makes me pretty
sure.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]