Re: SIGPROF + SIGCHLD and igc

[Helmut Eller <eller.helmut@gmail.com>]

On Tue, Dec 24 2024, Gerd Möllmann wrote:

[...]
> Anyway, what I see here: SIGCHLD doesn't do anything dangerous in the
> signal handler. Instead, the occurrence of SIGCHLD is added to a queue
> with enqueue_async_work and that's basically it.

Wrong branch!  enqueue_async_work doesn't exist in master.  ISTR that in
master it iterates through process-list.  Also, Pip said something that
the queue is not signal safe, because signals can nest or something like
that.  Also, Eli didn't like enqueue_async_work much.

> My personal summary for SIGPROF + SIGCHLD at this point:
>
> - I recommend rewriting SIGPROF handling in the way I tried to describe,
>   possibly using the existing work queue mechanism. Everything else looks
>   too complicated to me.
>   
> - 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.
>
> - No longer wondering why macOS does not show any problems in that whole
>   area. The only problem is SIGPROF accessing Lisp objects, and the
>   memory barrier is not a problem on macOS because it doesn't use
>   signals.
>
> Please double-check!

I think, SIGIO might cause trouble.  But that async IO code in process.c
is sooo hard to read.  I wonder if it would be simpler with threads,
e.g. one thread per Lisp_Process.

Helmut