bug#25214: 26.0.50; Interacting with user from threads other than the primary

[Eli Zaretskii]

> Date: Mon, 17 Sep 2018 21:41:47 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 25214@debbugs.gnu.org, tom@tromey.com
> 
> So what means do we have to interrupt a pselect call from another
> thread?

One simple idea is not to interrupt a pselect call, but instead to
make sure the main thread never waits for too long for pselect to
return.  We could arrange for acquire_global_lock to maintain a count
of the number of threads that are waiting to take the lock, and if
that number is positive, reduce the timeout we pass to pselect such
that it never waits for more than, say, 1 sec.  Then we need a way for
a non-main thread to wait until the main thread returns from pselect,
at which time the non-main thread could proceed with its own attempt
to read input, while the main thread is stuck waiting for the global
lock.