Re: Some experience with the igc branch

[Paul Eggert]

On 12/26/24 23:57, Eli Zaretskii wrote:
> > 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?

Yes, if they follow this part of the POSIX spec. I don't know of any 
that don't.


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

Yes, the signal handler runs in whatever thread the OS decides to 
deliver it to. While the handler runs, all other threads proceed 
normally. If the handler happens to run in a non-main thread, all it 
does is block the signal (so that its thread isn't bothered again by the 
same signal) and then use pthread_kill to resend the signal to the main 
thread. The handler then returns, which allows the non-main thread to 
proceed; if the non-main thread was in the middle of a syscall, that 
syscall may fail with errno==EINTR.


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

I don't know how Lisp threads work. But if they are OS threads, then if 
the other thread has the lock, the main thread will remain stuck until 
the other thread releases the lock.


> our profiler cannot profile non-main Lisp threads, because SIGPROF will
> always sample the state of the main thread?

Yes, but that's not the only reason. A quick look at the profiling code 
suggests that it is not thread-safe, so chaos would ensue if SIGPROF 
were not forwarded to the main thread.