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

[Pip Cet]

> > > We should either release the global lock before the thread exits, or
> > > defer the acting upon the signal until later.  We cannot disable the
> > > signal handling altogether because it is entirely legitimate to signal
> > > another thread, and when we do, that other thread will _always_ be
> > > inside thread_select.
> >
> > Really? What about thread-yield?
>
> What about it?
>
> You are asking whether, when thread-signal is executed, the thread
> which we are signaling is necessarily parked inside thread_select?  If
> so, I don't understand your surprise: only one thread can ever be
> running, and that is by definition the thread which calls
> thread-signal.  All the other threads cannot be running, which means
> they are parked either in thread_select or in sys_mutex_lock called
> from acquire_global_lock.  Right?

No, they might also be in the sys_thread_yield syscall, having
released the global lock but not yet reacquired it:

  release_global_lock ();
  sys_thread_yield (); <<<<< here
  acquire_global_lock (self);

> As for thread-yield, I'm not sure I understand how is it related to
> the issue we are discussing.

I'm not sure how it's relevant to assert that "that other thread will
_always_ be inside thread_select". I have an idea where you might be
going with that, but that idea wouldn't work (to release the lock from
the signalling thread, not the signalled thread that holds it).

> If the problem with missing events,
> then which events are those, and what bad things will happen if we
> miss them?

All events that glib knows about but Emacs doesn't. For example, a
glib timeout is apparently used to achieve some kind of scroll effect
on GTK menus, which is why we call xg_select from xmenu.c.

I don't know which libraries use glib-based threads, but I think dbus does, too.

I believe, but am not certain, that this also includes X events when
using GTK. That would explain the frozen sessions.