[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#25214: 26.0.50; Interacting with user from threads other than the pr
From: |
Eli Zaretskii |
Subject: |
bug#25214: 26.0.50; Interacting with user from threads other than the primary |
Date: |
Tue, 18 Sep 2018 11:34:36 +0300 |
> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: 25214@debbugs.gnu.org, tom@tromey.com
> 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.
bug#25214: 26.0.50; Interacting with user from threads other than the primary, Michael Albinus, 2018/09/18