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 <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: Mon, 17 Sep 2018 22:11:52 +0300

> Date: Mon, 17 Sep 2018 21:41:47 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 25214 <at> debbugs.gnu.org, tom <at> 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.

Previous Next

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