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

[Eli Zaretskii <eliz@gnu.org>]

> From: Pip Cet <pipcet@gmail.com>
> Date: Fri, 12 Jul 2019 18:06:29 +0000
> Cc: politza@hochschule-trier.de, 36609@debbugs.gnu.org
> 
> > Then we should make sure we release it when the thread function exits,
> 
> That's too late, it's legitimate for the thread to have a signal
> handler. We need to release the lock at precisely the time that
> unbind_to would release it.

I had also another proposal:

> > or before we call Fsignal from post_acquire_global_lock.  There's no
> > reason to use the unwind-protect machinery for that, I think.
> 
> If we call Fsignal, surely the unwind-protect machinery is already set
> up and we can safely call it? So unbind_to would work again...

Sorry, I don't want to call unwind-protect there.  Call me paranoid,
if you want.

> I guess I've changed my mind: the unwind-protect machinery does
> precisely what we want, we should simply document that thread_select
> can exit nonlocally and that the select functions need to be written
> to cater to that.
> 
> Two places call xg_select, and they both run long after unbind_to works.
> 
> Doing this without the unwind-protect machinery is difficult: for
> example, a comment in post_acquire_global_lock claims
> unbind_for_thread_switch can exit nonlocally, though I don't think
> that actually happens or we would have seen the bug report.
> 
> What's your proposal for doing this?

Like I said: release the lock before calling Fsignal.  We could do
that before calling unbind_for_thread_switch, if needed.