[Top][All Lists]

[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

From: Eli Zaretskii
Subject: 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 <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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]