Re: User interaction from multiple threads

[Eli Zaretskii]

> From: hw <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden,  address@hidden,  
> address@hidden
> Date: Wed, 29 Aug 2018 00:05:08 +0200
> 
> Imagine serializing requests and presenting them to users with the right
> amount of sequentiality and historical context was already solved.  What
> is Emacs supposed to do with requests after I start using it for
> programming and tell it that I am in do-not-disturb-mode?
> 
> That mode means that I do not want to be disturbed by any prompt which
> is not directly related to what I'm currently doing, i. e. it's ok for
> Emacs to ask me for a file name right away when I press C-x C-f.  It is
> definitely not ok to prompt me "FOO (y or n)" because Emacs is still
> copying or deleting files and wants to know something.  I'd look into
> the progress of that some time later, or the next day maybe.

Such a mode could be a useful feature, but we cannot assume all the
users will want to activate it.  We are looking for a way to allow
them to "be disturbed" by the background threads, but in a way that
will still allow to do something useful in the foreground.

> It is also not ok for gnus to change the size of the mini-buffer or to
> ask me for a password when it automatically checks for new mail every
> now and then.

Letting Gnus running in the background ask me for a password is
actually something we'd like to support.

> Since there is no such thing as "a foreground", Emacs has no idea what
> I'm doing and no way to decide which requests it may allow to reach me
> and which ones not.

The Lisp program with which you are interacting could help Emacs have
some idea about these things.

> While the user is not in do-not-disturb-mode, it doesn't matter which
> prompt is forwarded first.

I don't think the order matters.  I think the fundamental problems are
when it is okay to prompt the user, and how to indicate to threads
it's okay.

> >> Aren't the threads already managed in some way?
> >
> > No, not really.  There's a single global lock and a race to grab it
> > when it becomes released by whatever thread was holding it.
> 
> How is being decided for how long the most a thread can stall the
> others?

It can stall them indefinitely.  As long as the thread runs some Lisp
and doesn't call any of the "yielding" APIs, no other thread can run.

> What information is available when a thread is created?

See 'make-thread' for the gory details, but in a nutshell, just the
function which the thread will run and the optional name.
> >> Emacs could even assume the possible answers to a prompt and perform the
> >> actions resulting from the answers in some cases so that when the user
> >> makes a decision, the result is already available and the one not needed
> >> can be discarded :)
> >
> > I don't think this is possible in practice.  We usually ask the user
> > questions for which only the user knows the answers.
> 
> While (query-replace) is waiting for the user to answer its prompt,
> Emacs could anticipate the possibility that the user is going to perform
> all the possible replacements (after verifying only a few) and create a
> version of the buffer in which all replacements have been performed. Now
> when the user actually does what Emacs anticipated, it switches the
> buffers so the user doesn't need to wait for the replacements to be
> performed (assuming that would be faster than doing the replacements,
> for the sake of this example).

I think this strategy will fail most of the time: if the user wants to
confirm all the replacements, she will press '!' early on.  If they
keep pressing 'y' or SPC, my guess is that they want to skip some of
the matches.