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

[Eli Zaretskii <eliz@gnu.org>]

> From: dick.r.chiang@gmail.com
> Cc: larsi@gnus.org,  pipcet@gmail.com,  politza@hochschule-trier.de,
>   36609@debbugs.gnu.org
> Date: Sun, 06 Jun 2021 15:10:43 -0400
> 
> EZ> This will bring back bug#36609, so we cannot do that without
> EZ> discussing first why you think that commit was wrong.
> 
> By enforcing bijection between acquires and releases in xgselect.c --
> cavalierly so as the releases now come out-of-band from another module
> thread.c -- commit 9c62ffb admits deadlock.  The conditions under which that
> happens are not at all rarefied as evidenced by `for i in 1 2 3 ; do src/emacs
> -Q -l ./42.el & done ;`

You will have to provide a more detailed analysis, sorry.  The fact
that some Lisp can cause deadlock does not prove anything, there are
too many ways to write such deadlocking code.

> Generally, a commit made to remedy a phantom problem should always be
> suspect.  In this case OP was squatting on the main thread, so he deserves
> what he got.

That was not the analysis of that test case.  See the discussion of
the bug.  The problems with the GTK lock are real, not phantom.