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 22:00:52 +0200
>> 
>> >> 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.
>
> There's very little overhead, but if you are interested in the
> details, I suggest to read thread.c.  It's not a lot of code, and the
> ideas are quite simple.

I wish I had at least 50 lifetimes so I could do more of what I would
like to do.  Would you say that when a user is writing a function that
does some string replacements within texts that are usually between 16
and 64kB in size should use multiple threads to replace different
strings or not?

I would expect it to be slower because of the overhead unless multiple
threads could run at the same time.  Since they can't, what would be an
advantage of using multiple threads?

>> 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?
>
> Someone wrote a mode where you can list threads and display their
> backtraces.
>
>> What if the name is designed maliciously?
>
> Why would you run malicious code?  This is orthogonal to the issue
> being discussed here.

Because the names of the threads hide the fact that it is malicious so I
don't know that it is.

>> 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?
>
> These questions again are orthogonal to the issue at hand, I think.

Considering how the users can figure out what prompts mean and that they
sometimes may not want to be disturbed by unrelated prompts means
approaching the issue from a different angle while the technical problem
of how to prompt them can reasonably not be solved without such
considerations.

>> 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?
>
> So we will need to have machine learning in Emacs for this to work
> satisfactorily?

That would depend on what one is satisfied with.  Generally, well, why
shouldn't an editor or other software learn about the preferences and
the behaviour of its user and thus become able to yield a better usage
experience and better support with the work the user is using the
software to do?

Thinking of it, I much prefer software that kinda does that already;
only it doesn't do that by itself, so I have to do it --- by setting
preferences, writing my own functions, defining my own key bindings, for
example.  I wouldn't need to do all that if the software could figure it
out by itself.