bug#36609: 27.0.50; Possible race-condition in threading implementation

[Eli Zaretskii]

> From: Pip Cet <pipcet@gmail.com>
> Date: Fri, 12 Jul 2019 12:57:51 +0000
> Cc: politza@hochschule-trier.de, 36609@debbugs.gnu.org
> 
> Lisp Backtrace:
> "sleep-for" (0xedf7a530)
> 0xf6da40 Lisp type 3
> 
> post_acquire_global_lock () can return abnormally (I didn't know
> that), so really_call_select() can, too, so thread_select() can, too.

Do you know which code sets current_thread->error_symbol, and what is
that error symbol?

> > > +  ptrdiff_t count = SPECPDL_INDEX ();
> >
> > I don't think we should do that at this low level.
> 
> You're right, it does stick out. I think we're safe because we're
> calling Fsignal with the global lock held, but it's not a pretty or
> well-documented situation.

Is this the main thread which does that?  if so, there should be no
problem with holding the global lock in this case, is there?

If this is not the main thread, then the error handlers should be set
so as to log the error in last_thread_error, and then terminate the
thread (via exiting the thread function, AFAIR).

If this is not what happens, I'd like to know what does happen here,
and why.

Thanks.