Re: User interaction from multiple threads

[Uday S Reddy]

Eli Zaretskii writes:

> As a trivial example, consider 2 threads, one copying files, the other
> removing files. How do you know whether to confirm or not when the prompt
> says just "FOO (y or n)?"

At a minimum, the elisp coder would have to give fuller prompts, e.g.,

  copy FOO (y or n)?
  remove FOO (y or n)?

But still it is dangerous. If a "remove FOO?" prompt comes in the middle of
a series of "copy FOO?" prompts, the user is not going to notice that the
context has changed. The best solution is to lock the user interaction until
all the prompts of one kind are done.

> But in that case everything becomes sequential again, and we gained
> nothing by introducing concurrency into Emacs.  The only threads that
> will be able to run non-sequentially are those that never need to tell
> the users or ask them anything, and that makes this feature rather
> limited, I think.

In my view, the non-main threads asking for user interaction should be a
rarity. Ideally, the main thread should do all the interaction that is
necessary, and then spawn the sub-threads with all the information they
need. 

It is easy for us to generate a hundred threads. But it is not possible for
the user to create a hundred threads in their own head. So, yes, the user is
going to cut down the concurrency.

Cheers,
Uday