bug#25214: 26.0.50; Interacting with user from threads other than the primary

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> 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.