bug#56487: xgselect race condition leading to abort when USE_GTK not defined

[Tom Gillespie]

> Thanks.  Why did the code previously under !USE_GTK have to be removed?

When the !USE_GTK code is used an abort in glib will happen
stochastically due to an out-of-sync call to release_select_lock
in thread.c. This happens on my system somewhere between
approximately 1 in 10 and 1 in 10000 times that the test file
is run.

As far as I can tell from testing there is no difference in behavior
between the USE_GTK and !USE_GTK code. Also, as far as
I can tell from reading, the behavior should be almost identical.
The only addition is to check for already_has_events before
calling thread_select, which may be enough to shift the timing
to prevent a race.

I have not been able to figure out what the actual underlying
cause is (I tried). All I can say for sure is that there is
something that calls into g_main_context_release and
context->owner_count has a negative overflow to 4294967295.

I do not think that it is because something somehow sneaks
in between the calls to the atomics in acquire_select_lock
and relese_select_lock. If you would like I can send along
a couple of patches that include changes I made to try to
see what is going on.

The real underlying issue would seem to be that there is a
missing lock somewhere and that the use of atomics is not
sufficient, but I could be wrong about that.