Re: A UI approach for making synchronous commands asynchronous

[Eli Zaretskii <eliz@gnu.org>]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 01 Aug 2023 18:53:12 +0200
> 
> I was wondering what would happen if Emacs would adopt a
> one-thread-per-command strategy, i.e. every command starts out in a new
> background thread.

Based on past discussions, some of the problems with this are:

  . how to handle user interaction from such "background" commands
    (e.g., many commands ask the user for confirmation or prompt the
    user for input of some other kind, like file names)
  . how to trigger redisplay (and remember that some features, like
    messages in echo-area, are actually calls to redisplay in
    disguise)
  . how to handle timers started by some thread
  . how to handle output from subprocesses (a subprocess is by default
    locked to the thread which started it, but interesting stuff
    happens if that thread exits or dies)

But we definitely need to try to use threads more than we do, because
if not, we will never acquire solutions to these problems.