emacs邮件列表里在讨论多线程下的用户交互了, 有助于多线程的普及

http://lists.gnu.org/archive/html/emacs-devel/2018-08/msg00739.html

虽然有了多线程, 不过有不少使用上的限制, 用户交互就是一个, 这些限制可能是影响其普及的一大原因.

多个线程同时请求用户确认或输入文件名等内容, 只有minibuffer那么小一片区域, 还只能用文本, 界面是挺难设计.

感觉中文用户好像更在意用户界面和交互, 可以讨论一下, 集思广益.

1 个赞

既然在意 自己实现不就行了

人家不在意 也不会理你

emacs开发者也拿不定主意, 你有方案吗?

等C++的标准里有了GUI之后 这个问题自然就解决了

你这纯属空想了

用户也不能同时处理多个输入请求啊,难道不是只显示一个线程的请求,等用户输入完了再让下一个线程显示,这样么。。。

情况有点复杂, 比如是排队还是抢占, 假如每个线程有两个以上的交互在等候处理, 是交错提示还是让当前线程先来?

还有, 提示的时候怎么让用户知道当前对应哪个线程? 有时候可能需要把关联的buffer切换到前端, 配合提示一起, 方便用户做选择, 选完之后又要自动切回去.

另外正在输入文字的时候, 突然来了一个交互, 让用户输入y或n, 而当前输入的文字有可能正好是y或n.

类似于macOS的通知的方式怎么样

以下是我多年开发多线程图形程序的经验供你参考:

  1. 多线程的目的主要是, 把耗时的操作放到子线程中, 计算的时候, 不要影响UI线程的执行, 避免卡主用户的界面操作
  2. 一个进程同一时间只能由一个线程进行图形绘制, 多个线程同时进行图形绘制会导致操作系统底层报错, 比如 Unix/X11 的 “Bad Window” 段错误或者其他竞争性 X11 错误
  3. 一般的图形应用, 包括Emacs, 都是只有一个线程, 也就是主线程才能操作界面, 其他线程都只是计算结果以后, 把结果 post 给主线程, 然后由主线程来进行图形绘制

简而言之, 在Emacs中, 不论怎么设计多线程, 其实操作界面(比如 minibuffer ) 永远都只可能是主线程, 任何emacs插件其实只是做后台计算线程的工作.

至于楼主说的, 多个插件都等待用户输入的情况, 其实很简单, 现代操作系统的任务栏就是解决类似的问题的, 想象一下, 每个图形化应用相对于操作系统, 就相当于, emacs插件相对于emacs, 当有多个图形化程序需要输入的时候, 用户需要从任务栏先切换到对应的应用程序才能针对性的输入, 同样, emacs插件竞争输入的时候, 需要切换到emacs插件buffer或者让用户通过 minibuffer 进行手动切换线程列表才能切换输入焦点, 就像用户需要点击任务栏图标或者alt + tab 才能切换到后台应用程序.

所以, 比较好的交互模式是, 当前正在执行的插件独占minibuffer, 后台的子线程有需要minibuffer输入的时候, 通过 mode-line 的形式通知用户, 用户觉得有必要的时候, 先切换到后台线程后(不一定必须switch-buffer, 可以是类似helm的方式切换线程), 再由后台线程插件独占 minibuffer.

3 个赞

Emacs的多线程只适合一些非图形化的操作, 用于替换 async sub-process, 比如原来我写的 elisp-format.el 批量格式大量文件的后台操作, 可以用多线程来替换.

但是Emacs的多线程救不了图形界面的卡, 因为不管多线程怎么在后台计算, 最后都要在主线程绘制图形, 如果主线程的图形绘制每帧耗时超过 30ms 以后, 用户就会感觉明显的主线程卡顿甚至卡死 (想象一下, 后台线程下载完一个单反照片后, emacs的主线程无法在一个绘制周期完成单反图片的缩放和绘制就会卡顿甚至卡死emacs)

本质上多线程是为了图形编程服务的, 如果不是图形编程场景, 现代计算机的内存容量, 子进程的方式更方便和安全, 不会像多线程那样发生多个线程同时写冲突的问题.

1 个赞

emacs26的多线程,目前看来,不同线程几乎是平等的(除了信号相关的),每个线程都可以运行一样的lisp代码,包括刷新UI以及跟用户交互,但是emacs的界面元素又很少(要照顾terminal用户),不方便多线程的UI交互,假如有多个线程同时让用户输入内容(比如字符串或者文件名),可用的UI元素只有minibuffer,最多扩展到mode-line(尚未用过)。

操作系统的任务栏,通知栏,这些高级的东西,emacs上都没有,没法使用, 再考虑到terminal用户,能发挥的空间非常小。

我自己不喜欢emacs这种多线程设计,逻辑太复杂,容易混乱,而且朝这个方向发展之后,真正的并发将更难实现(现在是伪并发)。一个主线程加多个后台线程的模式更好。

26之后有段时间(包括git里的27),调整frame大小的过程会出现竞争条件。不过我发邮件之后没有讨论出所以然来。不知道调整frame大小相关的过程被多线程化了没有。。。

有没有详细一点的信息?

我当时发邮件的时候犯蠢,用QQ邮箱是还是设的中文和复文本(事后知道可以设置英文和纯文本),有很多讨论mail list看不到,不过还是可以看看是什么bug。而且这个bug在回复我的那个人的电脑上也复现了。