Re: Some experience with the igc branch

[Eli Zaretskii]

> Date: Fri, 27 Dec 2024 11:34:12 -0800
> Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, pipcet@protonmail.com,
>  emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> > 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.

And when the thread to which the OS delivered the signal calls
pthread_kill to deliver the signal to the main thread, does that stop
only the main thread?  That is, do other threads keep running?

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

Really?  Why?  The main thread is stuck in taking a mutex, which AFAIU
is a system call?  Then delivering a signal to the main thread should
terminate the syscall, and the main thread should execute the handler
code for the signal it got delivered, no?  (And yes, Lisp threads are
OS threads; in particular, on Posix systems they are pthreads
threads.)

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

"Not thread-safe" in what way?  Only one Lisp thread can run at a
given time, so some thread-safe issues should not exist in that case.