Re: User interaction from multiple threads

[hw]

Eli Zaretskii <address@hidden> writes:

>> From: Richard Stallman <address@hidden>
>> Cc: address@hidden, address@hidden,
>>      address@hidden,
>>      address@hidden
>> Date: Wed, 22 Aug 2018 00:05:58 -0400
>> 
>> Is it necessary to support user interaction from multiple threads
>> on any given terminal?  If not necessary, is it worth the trouble?
>
> IMO, it is worth the trouble.  If we don't provide a way of coping
> with that, the concurrency feature will be much less useful than it
> could have been, because only a very limited class of Lisp programs
> will be able to run in non-main threads.
>
> The case in point is Michael's work on the tramp-thread-safe branch:
> there' visiting files and other file-related commands run in another
> thread (useful for commands that take a lot of time to complete, such
> as accessing remote files via Tramp).  The code does it by running
> normal file primitives in separate threads.  However, some primitives
> and subroutines need to ask the user something, such as whether to
> apply file-local variables that might be unsafe, and need the user to
> respond.  If we decide that user interaction from other threads is
> "verboten", it means all such mundane operations, of which we have
> gazillions in Emacs, suddenly become impossible to use in a program
> that could run in another thread, and then what do we expect Lisp
> programmers to do about that? invent a whole new set of parallel
> functions that somehow avoid asking such questions or prompting the
> user when they need to?
>
> IOW, limiting user interaction to a single thread will in practice
> allow running in other threads only programs that never interact with
> the user, such as some batch-style mathematical calculation or text
> processing.  Most Emacs Lisp programs are not like that.
>
> The whole point of introducing threads was to allow running code
> asynchronously with minimum fuss.  If it turns out that the amount of
> fuss is much larger than that, then we gained nothing, because we can
> already run "asynchronous" code from timers and process filters, given
> enough effort to make a program abide by the rules necessary to work
> in such situations.
>
>> If it is ok not to support that, maybe we should take a different
>> approach, such as assigning any given terminal to one thread.
>
> Unless I misunderstand what you mean by "given terminal", doing that
> won't solve the hard part of the problem: how to multiplex input
> events between different threads which require user attention
> simultaneously.  That's because, AFAIR, even with multiple displays,
> we still serialize input: once I start typing a key sequence on one
> display, the others won't accept any input until I finish.

Assuming that

+ for a number of reasons, users can not deal with multiple
  requests for input (RFIs) at the same time anyway,

+ that inevitably Emacs will create multiple RFIs at the same time when
  using multiple threads

+ and that it can be agreed upon that users must not be interrupted by
  RFIs and should not be confused by them

what other choice is there than queueing up the RFIs and leaving it to
the users to work their way through the queue as they see fit?

The only RFIs users probably want to deal with immediately are the ones
directly related to what they are currently doing, like being prompted
for a file name when they want to visit one.

All others need to be queued.  With time, further options may come up,
like classifying RFIs and options to decide which instances the users
want to be brought to their attention right away, and multiple RFI
queues for different classes and/or with different priorities to them
assigned by the users simply through the order in which they choose to
go through them.


For example, when desktop-mode loads a session which contains buffers
that make Emacs prompt for unsafe variables, the RFI should be queued,
multithreading or not, so Emacs can proceed visiting files.  During the
current session, I might never touch the buffer which is asking about
unsafe variables, so why should I have to deal with the RFI at all?
Only if I want to do something with this buffer, I should be presented
with it.

>From a useability point of view, it doesn´t make any sense that Emacs
grinds to a halt during restoring a session when restoring it creates an
RFI and tries to force me to deal with it.  That´s not what I want, so
in practise, I have to make sure not to have files restored that cause
RFIs.