Re: User interaction from multiple threads

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 30 Aug 2018 22:12:35 +0100
> From: Uday Reddy <usr.vm.rocks@gmail.com>
> Cc: Uday S Reddy <usr.vm.rocks@gmail.com>,
>     emacs-devel@gnu.org
> 
> Put the entire Gnus into a thread? That sounds rather ambitious.

And yet this is one of the first things people tried as soon as
concurrency landed on the master branch.

> But, more to the point, I don't see what purpose it serves. That Gnus thread
> will hang while it is downloading news and the user is left twiddling his
> thumbs. Threads can only be useful if Gnus is *modified* to relegate the
> network activity to background threads, so that Gnus itself remains
> responsive. That can only be achieved if Gnus is purposely rewritten for
> that purpose. No free lunch.

Not so: since Gnus reads the newsgroups by using APIs like
accept-process-output, the user could still do something useful while
Gnus waits for the server to respond.

IOW, reading newsgroups is a series of calls that accept stuff from
the server, and the thread infrastructure lets the main thread kick in
between the calls.

> The effect of a "Gnus thread" can already be achieved by just starting a
> separate Emacs session for Gnus. Why bother with threads just to replicate
> the same behaviour?

Because (a) you don't need another process, and (b) you can start
reading the new messages before Gnus is done downloading everything.
IOW, exactly for the same reasons it is better to run "M-x compile"
asynchronously instead of in another Emacs session.

> Think of ELPA. You fill out a huge form telling it everything you want it to
> do. Then it goes off and does it. No quesitons asked.

I think this will be a small subset of what people want to do without
locking up Emacs.  Many Lisp programs do most of its job silently, but
do need to ask a question or two from time to time.  There's no need
to give up on running such jobs on non-main threads.

> You seem to want "foreground threads", which handle buffers and frames etc.
> to do one kind of activity the user is wanting to do.

Correction: it's not me, it's Emacs users and programmers.  Case in
point: the feature/tramp-thread-safe branch.  It is not a coincidence
that the very first serious attempt to use the concurrency feature
bumped at these issues almost immediately.