Re: User interaction from multiple threads

[Uday Reddy]

Eli Zaretskii writes:

> This would be an unfortunate limitation, since it means people will
> need to write code intended to run in non-main threads specially.  As
> a corollary, many existing Lisp programs will have to be significantly
> rewritten to fit this scheme, before they can be safely run
> concurrently with some foreground job done by the main thread.  The
> proverbial example is to be able to run Gnus in a non-main thread so
> that its slow reading of the newsgroups would not block Emacs.

Put the entire Gnus into a thread? That sounds rather ambitious.

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.

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?

> > Ideally, the main thread should do all the interaction that is
> > necessary, and then spawn the sub-threads with all the information
> > they need.
> 
> I think this will be hard to do in Emacs, given the abundance of
> global state.

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.

Let us call these kind of things "background threads". They will have to be
designed carefully to touch as little global state as possible and there are
arrangements in place for correct sharing when they do touch global state. 

You seem to want "foreground threads", which handle buffers and frames etc.
to do one kind of activity the user is wanting to do. If that is what you
want, then I don't see what escape there is from giving each thread its own
minibuffer.

Cheers,
Uday