Re: Delivering SIGIO when several threads are active?

[Paul Eggert <eggert@cs.ucla.edu>]

[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]

Eli Zaretskii wrote:
> When SIGIO is received by some thread, we currently deliver it to the
> main thread, see deliver_input_available_signal and
> deliver_process_signal.  Is that appropriate when more than one thread
> is active?

Such signals have been delivered to the main thread for quite some time, and 
this has worked well enough; is there something different about the concurrency 
code that now makes this behavior inappropriate?

> The SIGIO handler just sets a global variable, so the
> handler itself is okay, I think, but is it okay to interrupt the main
> thread with SIGIO at some arbitrary point?  E.g., the main thread
> could be in some Xlib or GTK call.

These library functions are all supposed to work even if such handlers interrupt 
them.

> The comments to deliver_process_signal say:
>
>                  POSIX says any thread can receive a signal that is
>    associated with a process, process group, or asynchronous event.
>    On GNU/Linux that is not true, but for other systems (FreeBSD at
>    least) it is.
>
> What does happen on GNU/Linux?  Is there a specific thread on
> GNU/Linux which gets signals associated with a process?

On GNU/Linux, process signals get sent to the main thread unless the main thread 
is blocking them (or if a few less-common situations arise, e.g., the main 
thread is exiting).

> And if so,
> does this affect what we should do with SIGIO in this case?

I don't see why it would affect SIGIO handling.

I installed the attached to try to explain this better.

Hmm, I see that the recent changes use mixed terminology. Until now, Emacs has 
called the initial thread the "main thread", but the recent code sometimes calls 
it the "primary thread". We shouldn't have two names for the same thing. I'll 
look into fixing that.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-src-sysdep.c-deliver_process_signal-Improve-comment.patch --]
[-- Type: text/x-diff; name="0001-src-sysdep.c-deliver_process_signal-Improve-comment.patch", Size: 1418 bytes --]

From c971e9141d401a5cf4aae96d981d8eb8a9300ec2 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Fri, 30 Dec 2016 09:45:46 -0800
Subject: [PATCH] * src/sysdep.c (deliver_process_signal): Improve comment.

---
 src/sysdep.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/sysdep.c b/src/sysdep.c
index 86d420f..1ba336e 100644
--- a/src/sysdep.c
+++ b/src/sysdep.c
@@ -1616,14 +1616,17 @@ static pthread_t main_thread;
 #endif
 
 /* SIG has arrived at the current process.  Deliver it to the main
-   thread, which should handle it with HANDLER.
+   thread, which should handle it with HANDLER.  (Delivering the
+   signal to some other thread might not work if the other thread is
+   about to exit.)
 
    If we are on the main thread, handle the signal SIG with HANDLER.
    Otherwise, redirect the signal to the main thread, blocking it from
    this thread.  POSIX says any thread can receive a signal that is
    associated with a process, process group, or asynchronous event.
-   On GNU/Linux that is not true, but for other systems (FreeBSD at
-   least) it is.  */
+   On GNU/Linux the main thread typically gets a process signal unless
+   it's blocked, but other systems (FreeBSD at least) can deliver the
+   signal to other threads.  */
 void
 deliver_process_signal (int sig, signal_handler_t handler)
 {
-- 
2.7.4