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

[dick . r . chiang]

EZ> You will have to provide a more detailed analysis, sorry.

There is no guarantee the static variable `threads_holding_glib_lock`
introduced in xgselect.c in commit 9c62ffb is synchronized across threads.  As
such, relying on it becoming zero in time for release_select_lock() is fraught.
(If you add print statements, this particular heisenbug disappears, at least
on Linux kernel 4.15.0-99-generic).

Four attachments:

1. Desired patch to master (reverts 9c62ffb, adds main-thread-p check).

0001-Only-acquire-glib-context-if-main-thread.patch
Description: Text Data

2. OP's original "my code doesn't work, here you figure it out", obfuscated MRE
Run as:
for i in 1 2 3 ; do src/emacs -Q -l ./report-orig.el & done
Fails if:
One of the emacsen stops responding

report-orig.el
Description: application/emacs-lisp

3. "Affine" redaction of OP's MRE *infrequently* breaks on tip of master 
(succeeds
after patch)
Run as:
for i in 1 2 3 ; do src/emacs -Q -l ./report.el & done
Fails if:
One of the emacsen stops responding

report.el
Description: application/emacs-lisp

4. My MRE *frequently* breaks tip of master (succeeds after patch)

42.el
Description: application/emacs-lisp

Run as:
for i in 1 2 3 ; do src/emacs -Q -l ./42.el & done
Fails if:
One of the emacsen stops responding