Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A vision of a multi-threaded Emacs

coredumped.dev

Post reply on HN
Print view View original

11–20 of 136 posts

Re: A vision of a multi-threaded Emacs

#11

Post by brabel »

CJefferson wrote: post #5

Note: Not at all an emacs expert, but know some stuff about trying to parallelise a long-standing language ( GAP -- www.gap-system.org , 30 year old maths language). I'd strongly recommend something like Javascript's "web workers", where each thread lives in an almost entirely independent memory space, with sharing limited to explicitly named buffers. The problem with traditional "everything shared by default" thread…

Yeah, I think that's the way... Dart does this well with Isolates[1]. The language is basically single-threaded but you can start Isolates that run on different Threads but have their own independent memory, and they can exchange messages, much like in the Actor model. Not having to worry about real shared memory between Threads as in C++ or Java is incredibly liberating. As others point out, however, for extremely high performance that's not the best solution, but for nearly all applications, including emacs, the Isolate approach is plenty good enough.

[1] https://dart.dev/guides/language/concurrency

Re: A vision of a multi-threaded Emacs

#12

Post by jonpalmisc »

metroholografix wrote: post #10
Kaze404 wrote: post #6

I'd love to see this someday, as an Emacs user. One of my biggest frustrations with Emacs is how it can simply just hang while waiting for anything IO bound (like a response from LSP). It mostly only happens when opening a new file, while in VSCode for example the file is opened immediately and things like LSP and syntax highlighting are loaded in the background.

That multi-threading will solve this issue, is a common misconception. Emacs already supports asynchronous I/O and has sentinels for exactly that. However, not everything that runs on Emacs is taking advantage of that functionality. It is therefore up to you, to use the proper package (or not use the wrong one) / configure Emacs in such a way, so that this sort of issue is avoided. I can definitely say that if you're…

Another vouch for Eglot here. Seems smoother and just nicer overall compared to lsp-mode, not to mention better integration with Emacs. I switched to Eglot a while back and haven’t looked back.

Re: A vision of a multi-threaded Emacs

#13

Post by Kaze404 »

metroholografix wrote: post #10
Kaze404 wrote: post #6

I'd love to see this someday, as an Emacs user. One of my biggest frustrations with Emacs is how it can simply just hang while waiting for anything IO bound (like a response from LSP). It mostly only happens when opening a new file, while in VSCode for example the file is opened immediately and things like LSP and syntax highlighting are loaded in the background.

That multi-threading will solve this issue, is a common misconception. Emacs already supports asynchronous I/O and has sentinels for exactly that. However, not everything that runs on Emacs is taking advantage of that functionality. It is therefore up to you, to use the proper package (or not use the wrong one) / configure Emacs in such a way, so that this sort of issue is avoided. I can definitely say that if you're…

Wow, I had no idea! I'll give Eglot a try, thank you :)

Re: A vision of a multi-threaded Emacs

#14

Post by Athas »

metroholografix wrote: post #10
Kaze404 wrote: post #6

I'd love to see this someday, as an Emacs user. One of my biggest frustrations with Emacs is how it can simply just hang while waiting for anything IO bound (like a response from LSP). It mostly only happens when opening a new file, while in VSCode for example the file is opened immediately and things like LSP and syntax highlighting are loaded in the background.

That multi-threading will solve this issue, is a common misconception. Emacs already supports asynchronous I/O and has sentinels for exactly that. However, not everything that runs on Emacs is taking advantage of that functionality. It is therefore up to you, to use the proper package (or not use the wrong one) / configure Emacs in such a way, so that this sort of issue is avoided. I can definitely say that if you're…

Joining the eglot choir. It behaves like I expect Emacs modes to behave and hooks into other Emacs functionality (xref, eldoc). Actually, it behaves better than that: it often works with zero configuration, which is much better than I expect.

Re: A vision of a multi-threaded Emacs

#15

Post by chrsig »

metroholografix wrote: post #10
Kaze404 wrote: post #6

I'd love to see this someday, as an Emacs user. One of my biggest frustrations with Emacs is how it can simply just hang while waiting for anything IO bound (like a response from LSP). It mostly only happens when opening a new file, while in VSCode for example the file is opened immediately and things like LSP and syntax highlighting are loaded in the background.

That multi-threading will solve this issue, is a common misconception. Emacs already supports asynchronous I/O and has sentinels for exactly that. However, not everything that runs on Emacs is taking advantage of that functionality. It is therefore up to you, to use the proper package (or not use the wrong one) / configure Emacs in such a way, so that this sort of issue is avoided. I can definitely say that if you're…

This is putting a lot of blame on the user, who likely has no clue how emacs i/o behaves.

> if you're experiencing I/O hangs, it's either misconfiguration or bad code in a package that you loaded

I mean...yes. That's the issue. The issue is that it's possible to have i/o hangs caused by misconfiguration or elisp packages.

The solution isn't to tell the user to do something different, it's to make it so that elisp execution can't cause i/o hangs.

edit: to a be a bit more precise with language: "i/o hang" should be interpreted as "making the UI unresponsive or preventing other tasks from completing".

Re: A vision of a multi-threaded Emacs

#16

Post by jlokier »

admax88qqq wrote: post #7
CJefferson wrote: post #5

Note: Not at all an emacs expert, but know some stuff about trying to parallelise a long-standing language ( GAP -- www.gap-system.org , 30 year old maths language). I'd strongly recommend something like Javascript's "web workers", where each thread lives in an almost entirely independent memory space, with sharing limited to explicitly named buffers. The problem with traditional "everything shared by default" thread…

WebWorkers are not very useful as a result. The communication overhead of copying data between two memory spaces usually dwafs any apeedups you could get from doing the work in parallel. It's easier to implement as a language and runtime, but to get truly high performance on today's many thread many core machines you need shar d memory concurrency more like Java

> to get truly high performance on today's many thread many core machines you need shared memory concurrency more like Java

JavaScript supports shared memory concurrency.

Shared memory¹ is available in browser WebWorkers these days.²

Atomic ops for building multi-threaded data structures³ are available too⁴.

Including primitives for thread synchronisation⁵⁶ used by mutexes, condvars, producer-consumer queues, etc.

¹ https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

² https://caniuse.com/sharedarraybuffer

³ https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

⁴ https://caniuse.com/mdn-javascript_builtins_atomics

⁵ https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

⁶ https://caniuse.com/mdn-javascript_builtins_atomics_wait

Re: A vision of a multi-threaded Emacs

#17

Post by rprospero »

metroholografix wrote: post #10
Kaze404 wrote: post #6

I'd love to see this someday, as an Emacs user. One of my biggest frustrations with Emacs is how it can simply just hang while waiting for anything IO bound (like a response from LSP). It mostly only happens when opening a new file, while in VSCode for example the file is opened immediately and things like LSP and syntax highlighting are loaded in the background.

That multi-threading will solve this issue, is a common misconception. Emacs already supports asynchronous I/O and has sentinels for exactly that. However, not everything that runs on Emacs is taking advantage of that functionality. It is therefore up to you, to use the proper package (or not use the wrong one) / configure Emacs in such a way, so that this sort of issue is avoided. I can definitely say that if you're…

While I appreciate the comments on Eglot vs LSP, the number one package that hangs my system is Gnus. It's still my favourite e-mail client, but I'm cut off from coding for twenty seconds every time I check my e-mail.

Are we really ready to declare that Lars Magne Ingebrigtsen is a substandard Emacs Lisp coder?

Re: A vision of a multi-threaded Emacs

#18

Post by KerrAvon »

CJefferson wrote: post #5

Note: Not at all an emacs expert, but know some stuff about trying to parallelise a long-standing language ( GAP -- www.gap-system.org , 30 year old maths language). I'd strongly recommend something like Javascript's "web workers", where each thread lives in an almost entirely independent memory space, with sharing limited to explicitly named buffers. The problem with traditional "everything shared by default" thread…

The author discusses essentially this option in "A jumping off point."

Re: A vision of a multi-threaded Emacs

#19

Post by rurban »

convolvatron wrote: post #8
CJefferson wrote: post #5

Note: Not at all an emacs expert, but know some stuff about trying to parallelise a long-standing language ( GAP -- www.gap-system.org , 30 year old maths language). I'd strongly recommend something like Javascript's "web workers", where each thread lives in an almost entirely independent memory space, with sharing limited to explicitly named buffers. The problem with traditional "everything shared by default" thread…

one really nasty conflating issue is that emacs uses a mess of globals. partially because of the domain but largely because of dynamic binding and the lack of namespaces. emacs really needs to be hoisted onto another language and runtime. everyone says this but no one can really conceive of doing this and rewriting or at least refactoring all the elisp extensions. I guess guile emacs is still alive? I should really t…

guile-emacs has atrocious string performance

Re: A vision of a multi-threaded Emacs

#20

Post by light_hue_1 »

metroholografix wrote: post #10
Kaze404 wrote: post #6

I'd love to see this someday, as an Emacs user. One of my biggest frustrations with Emacs is how it can simply just hang while waiting for anything IO bound (like a response from LSP). It mostly only happens when opening a new file, while in VSCode for example the file is opened immediately and things like LSP and syntax highlighting are loaded in the background.

That multi-threading will solve this issue, is a common misconception. Emacs already supports asynchronous I/O and has sentinels for exactly that. However, not everything that runs on Emacs is taking advantage of that functionality. It is therefore up to you, to use the proper package (or not use the wrong one) / configure Emacs in such a way, so that this sort of issue is avoided. I can definitely say that if you're…

> I can definitely say that if you're experiencing I/O hangs, it's either misconfiguration or bad code in a package that you loaded.

As an emacs user and package developer of 20 years I can definitely say you are totally wrong. This is the kind of dismissive, unhelpful, and frankly extremely discouraging attitude that is slowly killing emacs.

Instead of taking responsibility for the fact that emacs is incredibly slow because of poor architectural decisions (like an insistence to not using fast native libraries and an incredibly slow language), the solution is apparently to blame the people who create packages. If developers they are creating packages that are slow, it is not their fault. It is the fault of emacs developers in refusing to modernize the architecture in a way that enables people to make efficient code.

Post reply on HN