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

From: Eli Zaretskii <[email-masked]>
Date: Tue, 18 Sep 2018 11:34:36 +0300

> From: Michael Albinus <[email-masked]>
> Cc: [email-masked],  [email-masked]
> Date: Tue, 18 Sep 2018 10:29:25 +0200
> 
> > 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.
> 
> I'll see whether I could implement something along this idea. But I'm
> still learning Emacs' keyboard (more general: FD) handling, so it will
> take time.

It might help to search for timeout_reduced_for_timers in process.c:
that's how we implement a similar logic when timers are waiting to
run.