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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 10 Jun 2021 18:04:55 +0300

> From: [email-masked]
> Cc: [email-masked]
> 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.