Re: Some experience with the igc branch

[Eli Zaretskii <eliz@gnu.org>]

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

OK.

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

OK, then this is just terminology differences.  What you describe is
the expected result.

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

Yes, that's the purpose of the global lock: a Lisp thread can only run
if it acquires the lock.

Thanks.