Re: SIGPROF + SIGCHLD and igc

[Gerd Möllmann]

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

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

Oops, thanks for checking! And 👍 to Pip. Then we have to see what to do
with nested signals if that's a problem.

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

It's a maze :-(.

BTW, do you agree with my analysis that Lisp allocations can't possibly
exist in signal handlers today?