[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: Michael Albinus
Subject: bug#25214: 26.0.50; Interacting with user from threads other than the primary
Date: Thu, 27 Sep 2018 18:15:08 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

Hi Eli,

>> > 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.

For the time being I concentrate on tasks I feel better suited, like
adding thread support for further file operations.

Best regards, Michael.

reply via email to

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