emacs 为啥不支持多线程啊。如果支持多线程,那emacs要怎么设计?

说不定重开一个neo emacs会起飞

Guile Emacs 只是想革 ELisp 的命吧?就算革命成功,也不改 Emacs 本质。

vim其实也是单线程的程序,neovim也没办法改变vim单线程的问题。但是neovim使用了lua作为配置语言,lua配合libuv想要多线程啥的就很容易了,但是所有legacy的vim的东西,比如buffer,ui,tab。window之类的东西,都是没办法在子线程里访问的。但是luajit确实就是快,再加上vim本身没有很重的ui渲染(始终是一个终端的编辑器),所以单线程的问题其实并没有在这边体现的很严重。

多开lua虚拟机?

渲染都是在主线程做的啊,安卓在主线程跑阻塞的任务也卡

Gtk+陷阱与进阶技巧 我十多年前给 deepin 团队做的内部培训的PPT, 大家可以看一下。

很多没有图形编程经验的人区分不了操作系统并发多线程、 应用或语言内部实现的协程的区别。

图形编程不卡的关键核心不是主线程运行的代码或语言性能要多高, 因为一个屏幕的图形绘制都是常量性能要求, 关键是要完全并发运行的后台线程要分担非图形的耗时代码出去, 不要影响主线程绘制就可以了。

而所有协程的实现(Haskell、 Golang和Emacs等)的原理是自己做线程调度, 一瞬间只有一个线程在跑, 这种原理都不能完全解决图形卡顿的问题,因为一旦非图形线程耗时太长, 协程根本没法停掉非图形线程, 也会导致主线程因为没有得到事件循环和绘制的机会而卡顿。

而这个话题之所以翻来覆去的说, 是因为很多Emacser自己并没有自绘控件和并发多线程的编程经验, 没有实际实践过的人就傻傻的分不清楚协程和操作系统线程的区别。

协程的应用场景是服务器后台IO密集、 CPU不密集的场景, 来回切换协程资源占用少, 并不适合图形编程。

9 个赞

golang 这种有栈协程,好处就时切换的时候快的飞起, 但是runtime确实非常的重。
它这种模式倾向于公平调度的场景,不适合gui的绘制,绘制的主线程 每16ms至少分到10ms做事情才不会有卡顿感。

golang不是一个线程的吧,只是一个线程只会在某一瞬间被一个协程占用,但是协程与协程之间是并行的

lua的协程才是单线程的

真正的图形多线程,主线程绘制线程和后台非图形线程之间是不需要切换的,快速切换的都是语言自己实现的协程。

协程代码没有执行完之前是没法切出去的。

可以搜索一下为什么所有图形库都要支持多线程和事件循环。

1 个赞