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

Previous Next

Full log

Message #25 received at 25214 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25214 <at> debbugs.gnu.org, tom <at> tromey.com
Subject: Re: bug#25214: 26.0.50;
 Interacting with user from threads other than the primary
Date: Tue, 18 Sep 2018 10:29:25 +0200

Eli Zaretskii <eliz <at> 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.

Previous Next

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