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

[Pip Cet]

On Sat, Jul 13, 2019 at 3:54 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > But I still would like to understand why we need to maintain a flag
> > per thread.

We don't. I had originally planned to make reacquiring the lock fail
gracefully if we can't spin-lock, but that didn't make it into the
patch, so it should be simplified as you suggest.

> Specifically, why not make this flag thread-independent, and have any
> thread release the context lock if that variable is non-zero?  I don't
> think it matters which thread locked the Glib context, we just need to
> release it once we emerge from thread_select, and do it before we
> might call Fsignal.  That the lock might be released by a thread other
> than the one which locked it shouldn't matter, I think, as long as we
> consider all the Lisp threads acting together on behalf of Emacs.

I agree entirely.