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

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

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.

For waiting of the non-main thread: maybe a mutex and/or condition
variable could do the job.

Best regards, Michael.