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

[Eli Zaretskii]

> From: dick.r.chiang@gmail.com
> Cc: 36609@debbugs.gnu.org
> Date: Thu, 10 Jun 2021 10:55:53 -0400
> 
> > You cannot have, for example, half of the bits of the variable set by one 
> > thread
> > and the other half by another thread.
> 
> I dunno, this seems like a sophomoric, rose-colored view of variable sharing
> without regard to caching, or really any generally accepted guarantees about
> POSIX threads.

Is it, really?

> > So can you describe what you think happens in your scenario that the
> > offending change that added threads_holding_glib_lock causes?
> 
> Two threads see `threads_holding_glib_lock` is "0" and both attempt
> acquiring the lock (line 43, xgselect.c)
> 
> Or, two threads see `threads_holding_glib_lock` as "2" and glib
> lock is never released. (line 37, xgselect.c)

And you can show a GDB backtrace with values of the variable that
supports that?  And tell how that explains the hang that you see on
the Lisp level?  These are the details that I was asking from the
first message you posted here.