Re: User interaction from multiple threads

[hw]

Eli Zaretskii <address@hidden> writes:

>> 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.

Maybe not all users will activate it, and I probably wouldn't activate
it all the time.  How to make Emacs causing disturbances from the
background is a technical problem; disturbing users in what they are
doing is a usability problem.

If Emacs was disturbing me while I'm programming, I would have no choice
but to switch to a different editor.  Letting aside the loss of time and
the annoyance, the rate of errors goes up tremendously when I'm being
disturbed, and fixing them also costs time.  It is devastating for
productivity.

>> 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.

That already works since a long time.

>> 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.

That would be good.

> [...]
>> >> 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.

That's bad.  Last week I had tramp block me because it couldn't create a
backup file, and it was impossible to interrupt that.

>> 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.

Hm.  I wish the description would also say how much overhead is involved
in creating a thread to give us some idea about when to start a thread
and when not.

Knowing only the name of a function and maybe a name for the thread is
not much.  What if the function calls other functions which prompt the
user?  Is it possible to show a backtrace so the user can get some idea
about what might have caused the prompt to appear?  What if the name is
designed maliciously?

Also, the user goes like "I want to copy files" rather than "I want to
call this function".  I call functions when I can't remember what
keystrokes to use but have an idea of how the function may be called.
How is the function called that deletes files?  Does that depend on
whether the files are remote or local?  What do I do when I can't figure
out what Emacs wants to know when it shows a prompt?

>> >> 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.

The strategy would have been successful when the user pressed '!' and
had Emacs perform all replacements so far.  It doesn't matter when she
does that unless she does it when it takes longer to switch buffers than
it takes to do the rest of the replacements.

If Emacs learns that she usually does not press '!', it could change its
strategy :)  But when it can prepare stuff using another thread, what
does it matter when it's wrong?