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

[Eli Zaretskii]

> From: Pip Cet <pipcet@gmail.com>
> Date: Fri, 12 Jul 2019 14:34:44 +0000
> Cc: politza@hochschule-trier.de, 36609@debbugs.gnu.org
> 
> > > When a thread is signalled (by thread-signal, which sets another
> > > thread's error_symbol) while the signalled thread is inside a
> > > select(), thread_select() will return non-locally for that thread, and
> > > we fail to release an internal GLib lock through
> > > g_main_context_release(). That's the first bug.
> >
> > 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?

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

> > For the main thread, handling the signal in that situation shouldn't
> > be a problem, because it is not going to exit.  Right?
> 
> I think the main thread can still fail to release the lock...

Since the main thread doesn't exit, but just longjmp's to top-level,
and then continues to run, why does it need to release the lock?  Any
thread should hold the lock for as long as it runs.

> > > When xg_select() fails to acquire the internal GLib lock, it simply
> > > does a select() on the remaining file descriptors:
> >
> > Why does it fail to acquire that lock?
> 
> Because another thread holds it, either an Emacs or a non-Emacs
> thread.

OK, and why is it a problem that we continue calling thread_select
regardless of the failure to acquire the Glib lock?  is the problem
this one:

> In both cases, I think we might miss events unless we return
> with errno == EINTR.

?  Or is there something else?  If the problem with missing events,
then which events are those, and what bad things will happen if we
miss them?