Re: User interaction from multiple threads

[Eli Zaretskii <eliz@gnu.org>]

> From: Richard Stallman <rms@gnu.org>
> Cc: psainty@orcon.net.nz, gazally@runbox.com,
> 	emacs-devel-bounces+psainty=orcon.net.nz@gnu.org,
> 	emacs-devel@gnu.org
> 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.