[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
bug#25214: 26.0.50; Interacting with user from threads other than the primary
Thu, 27 Sep 2018 19:20:02 +0300
> From: Michael Albinus <address@hidden>
> Cc: address@hidden, address@hidden
> 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?
bug#25214: 26.0.50; Interacting with user from threads other than the primary, Michael Albinus, 2018/09/18