Subject: Re: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault

From: Eli Zaretskii <[email-masked]>
Date: Wed, 27 Aug 2025 22:22:09 +0300

> Date: Wed, 27 Aug 2025 11:11:34 -0700
> Cc: [email-masked], [email-masked]
> From: Paul Eggert <[email-masked]>
> 
> On 2025-08-27 09:51, Eli Zaretskii wrote:
> > didn't you tell me at some
> > point that on GNU/Linux the OS takes care of delivering fatal signals
> > to the main thread?
> 
> What I recall saying long ago is pretty much what I wrote earlier today, 
> namely that if a fatal signal is delivered to a non-main thread, Emacs 
> code in the non-main thread arranges to redeliver the signal to the main 
> thread.
> 
>    If that is so, then we have no control on what
> > happens with the global lock in this case, because
> > deliver_thread_signal is bypassed, and we might find ourselves in the
> > situation whereby a non-main thread was running some Lisp, then
> > triggered a fatal signal or some external source delivered a fatal
> > signal, and the OS runs the signal handler on the main thread which
> > doesn't own the global lock.  Is this possible?
> 
> Sounds like it, yes. It could also happen if the kernel decides to 
> deliver the externally-sourced signal to the main thread in the first 
> place. POSIX allows this.

OK, thanks.  So we still need to have some device in place for if and
when that happens, if we want to be able to run Lisp from the signal
handler.