Hacker News new | ask | show | jobs
by medstrom 1279 days ago
Please DON'T use the threads. As of 2018 it has many data races (https://nullprogram.com/blog/2018/05/31/), and resultant bugs will be a nightmare to track down.

The Emacs community has always got by through finding other ways to ensure responsiveness. It's true that each individual user shouldn't have to spend that much time on configuration (Doom Emacs and such distros help here), but still: people who find it slow must have misconfigured something, and on profiling, they'll find at most 1 or 2 features of their config that's eating all the CPU cycles. These won't actually be hard to fix, for a programmer, and threads wouldn't have helped matters, and at best only have hid the CPU-eater.
1 comments
tmtvl 1279 days ago
Yes, that post was mentioned in the article I linked:

Even Emacs current threads library suffers from data races which is one of the reason I believe it has not seen much adoption.

(where suffers from data races is a link to Chris Wellons' post).

The idea now is, as Chris states:

There really needs to be a safe, high-level API with clean thread isolation. Perhaps this higher-level API will eventually build on top of the low-level threading API.

While you are right that for 99% of standard usage single-threaded code is entirely fine, not utilizing between half to 15/16ths of potential processing power is a bit of a shame, especially considering it means doing something like indexing an entire project (yes, we can use GNU Global) will require the user to just sit and wait.

link
medstrom 1279 days ago
That "99% of standard usage" is the kicker, isn't it? The greybeards who opposed multithreading since the beginning tend to say that the remaining 1% of use cases is best done in an external process, ideally not even written in Emacs Lisp, so that Vimmers and the rest of the free software community can benefit. The GNU Global you mention embodies that ideal exactly.

I suppose if you still want that program to be written with Emacs Lisp, you could use async.el (https://github.com/jwiegley/emacs-async/) and there's finally an use-case for the threads: it'll be relatively safe to run those 16 threads only in the external Emacs-process.

link