bug#28630: 27.0.50; C-g while a non-main thread is sitting crashes Emacs

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 05 Oct 2017 10:24:11 +0300, Eli Zaretskii <eliz@gnu.org> said:

>> Interestingly, some variants of the original recipe behave
>> differently with respect to C-g depending on the toolkit.

> For the record, on MS-Windows, both are interrupted.

I could make the Mac port interruptible also for Example 2 (with some
delay because it uses polling with SIGALRM rather than SIGIO).  I also
confirmed that Motif behaved like Athena.  Below is updated one:

Example 1:

(thread-join
 (make-thread
  (lambda ()
    (message "hello")
    (sit-for 2)
    (message "there"))))

Interrupted: GTK+, Athena, Motif, no toolkit, MS-Windows, Mac
Not interrupted: NS


Example 2:

(thread-join
 (make-thread
  (lambda ()
    (message "hello")
    (sleep-for 2)
    (message "there"))))

Interrupted: GTK+, MS-Windows, Mac
Not interrupted: Athena, Motif, no toolkit, NS

> The upshot of this is that doing keyboard I/O in non-main threads is
> inherently unportable.  Should we mention this in the manual?

In principle, the method I used for the Mac port is also applicable to
X11 (but probably not for NS where secondary threads cannot read
keyboard input).  Each pselect call not involving keyboard input
additionally monitors one side of a socket pair, and the SIGALRM
handler writes to the other side.  This way, a pselect call in a
secondary thread is unblocked when the signal arrived, and then it
tries to see if keyboard input is available when none of other threads
is monitoring the keyboard input channel.

An alternative way would be to forward the signal to all the Lisp
threads.  But it looked too much for many cases.

Having said that, I don't think we need the change like this urgently.
For now, we can see if the above method really works for more
complicated situations using the Mac port.

                                     YAMAMOTO Mitsuharu
                                mituharu@math.s.chiba-u.ac.jp