[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some experience with the igc branch
From: |
Eli Zaretskii |
Subject: |
Re: Some experience with the igc branch |
Date: |
Sun, 29 Dec 2024 07:47:01 +0200 |
> 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.
- Re: Some experience with the igc branch, (continued)
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/26
- Re: Some experience with the igc branch, Helmut Eller, 2024/12/26
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/26
- Re: Some experience with the igc branch, Helmut Eller, 2024/12/26
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/26
- Re: Some experience with the igc branch, Paul Eggert, 2024/12/26
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/27
- Re: Some experience with the igc branch, Paul Eggert, 2024/12/27
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/28
- Re: Some experience with the igc branch, Paul Eggert, 2024/12/28
- Re: Some experience with the igc branch,
Eli Zaretskii <=
- Re: Some experience with the igc branch, Paul Eggert, 2024/12/29
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/29
- Re: Some experience with the igc branch, Paul Eggert, 2024/12/29
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/29
- Re: Some experience with the igc branch, Paul Eggert, 2024/12/30
- Re: Some experience with the igc branch, Gerd Möllmann, 2024/12/25
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/25
- Re: Some experience with the igc branch, Gerd Möllmann, 2024/12/25
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/25
- Re: Some experience with the igc branch, Gerd Möllmann, 2024/12/25