[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A UI approach for making synchronous commands asynchronous
From: |
Eli Zaretskii |
Subject: |
Re: A UI approach for making synchronous commands asynchronous |
Date: |
Tue, 01 Aug 2023 20:11:25 +0300 |
> 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.