GNU bug report logs - #25214
26.0.50; Interacting with user from threads other than the primary

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 25214 <at> debbugs.gnu.org, tom <at> tromey.com
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 <at> gmx.de>
> Cc: 25214 <at> debbugs.gnu.org,  tom <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.