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

Previous Next

Package: emacs;

Reported by: Eli Zaretskii <eliz <at> gnu.org>

Date: Fri, 16 Dec 2016 15:19:02 UTC

Severity: normal

Merged with 32426

Found in versions 26.0.50, 27.0.50

Full log


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

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: Re: bug#25214: 26.0.50;
 Interacting with user from threads other than the primary
Date: Thu, 27 Sep 2018 19:20:02 +0300
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: 25214 <at> debbugs.gnu.org,  tom <at> tromey.com
> Date: Thu, 27 Sep 2018 18:15:08 +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.
> 
> I've played for a while with the keyboard related code, and I must
> confess I'm too dumb for this. Sorry, but it is too much, and I have the
> feeling I cannot contribute something useful in this area. So I let this
> to be fixed by somebody else. This is a pity, because it blocks further
> progress in merging the branch feature/tramp-thread-safe into master.

Can you describe what exactly would you like someone else to
implement?  IOW, what minimal change will allow you to continue your
work in this direction?

Thanks.




This bug report was last modified 6 years and 192 days ago.

Previous Next


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