Re: Some experience with the igc branch

[Paul Eggert]

On 12/28/24 00:06, Eli Zaretskii wrote:

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

Yes.

The main thread doesn't stop; it merely gets a signal queued for 
delivery. Eventually the main thread's signal handler will be invoked.


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

By "remain stuck" I meant that the main thread will remain waiting for 
the lock if the signal handler returns normally.

pthread_mutex_lock is not an EINTRish syscall: it does not fail with 
errno==EINTR when interrupted. Instead, if the signal handler returns 
normally pthread_mutex_lock resumes waiting for the mutex. In GNU/Linux, 
pthread_mutex_lock typically operates entirely in user space: no syscall 
is involved.


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

I didn't know that only one Lisp thread can run at a time. If in 
addition Lisp threads can't be preempted by other Lisp threads being 
profiled, the profiling code is quite possibly safe to run in non-main 
Lisp threads, though this should be checked by an expert in that part of 
the code.