Re: Some experience with the igc branch

[Eli Zaretskii]

> Date: Thu, 26 Dec 2024 15:29:29 -0800
> Cc: gerd.moellmann@gmail.com, pipcet@protonmail.com, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 2024-12-26 07:23, Eli Zaretskii wrote:
> >> From: Helmut Eller <eller.helmut@gmail.com>
> >> I thought deliver_process_signal was there to forward signals to the
> >> main thread but you certainly know better what it does and doesn't.
> > 
> > Actually, we need Paul Eggert to chime in, because he knows much more
> > about this than I do.  We have arrangements for when a signal is
> > delivered to a thread, but I think Paul said this should rarely if
> > ever happen.
> 
> Helmut's right: deliver_process_signal arranges for the handler to be 
> called in the main thread even if the thread was delivered to some other 
> thread.

Is this true also on Posix systems other than GNU/Linux, though?

> And to some extent you're right, too, on GNU/Linux, where historically 
> this rarely happened unless the signal was blocked in the main thread. 
> That part of the Linux kernel has evolved, though, and I don't know 
> whether this is still true. However, whether it's true shouldn't affect 
> the correctness of deliver_process_signal.

Can you tell what happens during the short window between the signal
being delivered to a thread and until it is redirected to the main
thread?  Specifically, are the threads other than the one which git
hit by the signal still running until pthread_kill stops the main
thread?  This could be important for us to understand what could
happen if the signal hits the MPS thread or another non-Lisp thread in
Emacs.

Btw, init_signals initializes main_thread_id to the main thread of the
Emacs process, and AFAICT this is never changed during the session.
So what happens if, when the signal arrives, the main thread is stuck
in acquire_global_lock trying to take the global lock while some other
Lisp thread runs?  AFAIU, this means, among other things, that our
profiler cannot profile non-main Lisp threads, because SIGPROF will
always sample the state of the main thread?