You must log in or register to comment.
A lot of very useful software is not multithreaded. Hell, javascript is not multi-threaded.
It’s a dealbreaker for certain applications (e.g., window management). It’s not a dealbreaker for Emacs as a whole.
Actually, to be clear: most of the pain is with blocking I/O. But Emacs does have support for asynchronous I/O. The problem is that there is too much code that uses blocking I/O rather than asynchronous I/O.
The only “performance” issue for me is lsp - but that tends to be at first run on a large framework. And since my “old” laptop (x1c6) is about 1000x faster than the one I started using emacs on in the early 2000s it really isnt an issue.
Less haste, more speed…
I dream of a world gnus wont hang emacs.
I guess you should try Commercial Emacs, then.
If the author could only communicate better and bring his changes upstream…
I tried to see what do make of his first patch against Emacs 28 that bring threading to Gnus however it was quite hard to rebase/split them up as the original patch was just one big blob.
E.g. he doesn’t just add threading to Gnus but also remove or rename variables, e.g. secondary select methods. He doesn’t explain changes, he adds unnecessary or rude comments to the commits or code.
I didn’t say it would be easy. ;)
If you want a multithreading Emacs contribute to https://github.com/lem-project/lem. That will probably get you there faster than with Emacs.
Truth is it isn’t Emacs that you want, but the features it has. Just replicate them in Lem.