bug#37892: 27.0.50; Crash when signaling a thread

[Eli Zaretskii <eliz@gnu.org>]

> From: Michał Krzywkowski <mkrzywkow@gmail.com>
> Cc: Michał Krzywkowski <mkrzywkow@gmail.com>,
>  37892@debbugs.gnu.org
> Date: Sun, 27 Oct 2019 11:16:03 +0100
> 
>     >> I actually don't care (and can't know) what another thread is doing, I
>     >> just want to send a signal to it.
> 
>     Eli> But thread-signal is not for causing an error in a thread, it is for
>     Eli> unblocking a thread that waits on a mutex or a condvar.  So why would
>     Eli> you use it when the thread is not blocked?
> 
> Then I think documentation for that function should be changed to
> explicitly say that the signal will *only* be delivered if the target
> thread is in a "blocked call to ‘mutex-lock’, ‘condition-wait’, or
> ‘thread-join’".
> 
> Currently, the docstring of thread-signal just says that the function
> will interrupt threads which are blocked, but does not actually say that
> the signal will be delivered only in those cases.  In fact, it says that
> it works like signal, so I don't think it's unreasonable to assume that
> it will just interrupt a thread whatever it's doing.

The function does work like a signal, but Emacs cannot be interrupted
while it waits for input.  In all other cases your signal will be
delivered, and if unhandled, it will terminate the thread.

If we decide that thread-signal will have no effect while a thread
waits for input, then we will document that, of course.  My question
was meant to understand your intent for signaling a thread at
arbitrary time, because the effect of that is unpredictable, even if
the crash didn't happen.  I wanted to understand your thinking and
rationale, so as to have a better basis for the decision of how to fix
this problem.

So could you please elaborate on your rationale?

Thanks.