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

我之前试过common lisp 开发的lem 但是说实话有点卡手

但是如果支持多线程又要解决一些设计问题。 比如多个线程竞争刷新界面(暂时只想到这一个 :rofl:)。

不过我了解过unity的做法,单开一个主线程以60fps 去刷新界面,其余的线程不可以直接修改界面,只能委托主线程修改界面。

这里开个讨论贴,要是emacs要支持多线程,应该怎么设计emacs。 :point_left:

lazycat 的 eaf 已经提供了思路了吧

为啥不支持?

因为设计之初就没考虑到多线程。等到它成为问题时,代码已经堆成了“屎山”,并且已经形成了围绕着“屎山”的生态圈。谁也不敢贸然改动,一动就塌了。

为今之计就是,“屎山”的代码继续留在“屎山”,旁边另外堆一座小的,做好规划,两山并立,然后捡那要紧的“屎”一点一点搬过去。日复一日年复一年,赶在脑机接口到来之前,应该能用上流畅的 Emacs。

4 个赞

双线并行的难点是,需要单独给每个用到的API做线程隔离处理,保证访问新API不要影响旧的单线程API,这个工作量非常之大,同时还面临单线程API在新增功能的同时,新的API和旧的API功能上不能有太大差异。

这是理论上可能,但是在emacs社区没有强力领导的存在,基本上就是不可能。

现在马上可以实现的参考方案: 图形用EAF类似的技术,非图形用lsp-bridge类似的技术,效果杠杠的,不需要修改emacs。

3 个赞

我把 EAF/lsp-bridge 算作双线并行的一种实现了,甚至更倾向这种形式。

这种外部实现多线程的方式,三方开发者可以自行评估可行性,率先迁移自己的包,不仰 Emacs 开发组的鼻息,好赖都是自己的锅。对用户来说,一些三方的包改坏了也打紧,至少还有 Emacs 兜底。

反而 Emacs 内部实现不太可行。如果短时间内完成改造,发一个破坏性更新的版本,会让所有的用户或三方包作者措手不及;如果循序渐进慢慢改造,则长期双线并行,必定消耗大量的人力。

6 个赞

多线程编程有共享内存, 用起来很麻烦, 各种 mutex condvar, 设计 API 时也要考虑是不是 thread safe 的. 最简单的访问一个defcustom定义的全局变量, 在多线程条件下就得加锁访问.

如果要接上第三方的 C 库, 那要是线程不安全的代码在多线程条件下执行了, 就出问题了.

再加上 Emacs 最开始也没现在这么多功能, 所以选择了简单的单线程

2 个赞

cooperative multithread,或者干脆同一时间只有一条线程在运行

最大的问题是没人在写代码。真写完了顶多半年也能上线了

老风扇在改GC,改了GC后有可能改多线程吧 ,,,

说不能在emacs内部改的都是在给自己改不动emacs代码找借口而已。

我目前在读emacs的image.c,从这里入个门

6 个赞

协程并不能解决图形卡的问题,要真正并发多线程才行。

我现在org文件8.3M,4356个headline,每次搜索3级以上的headline,平均体感要等待4秒。

我希望在大的org文件中(20M以上),搜索较深的深度(6级深度)的headline,展开任意篇幅的headline,能够秒出,像vim那种反应速度就棒棒棒!

这个用 ripgrep 搜索就可以了。

3 个赞

谢谢提示,我学习下这个,哈哈

行动起来,革了屎山的命,我相信EmacsGay的能力

这个表述不太好 :rofl:,用复杂不好懂这种中性词可能好点 :joy:

1 个赞

老项目积重难返吗 :joy: :joy: 隔壁vim都开新坑neovim,结果nvim发展的还挺好

2 个赞

就我们公司的游戏项目,据说后端当时太急了就一个人。 当时我现在的老大一个后端 vs 8个前端。框架都没写就开始接业务了。 结果就是框架的并发数据重入问题到现在都没解决,不过好像是我来了才发现的就是了。 项目没那个量级,所以之前一直没出过问题。 但是虽然有这个问题但是却没人改,因为。。。。。。

上一个要革Emacs命的 Guile Emacs, 坟头草都三丈高了……就最近有人给上了个香

你说的就是我。。。。。。

我说的是那个提交的人 :smiling_face_with_three_hearts:

1 个赞