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.