Kyle Jones <kyle_jones(a)wonderworks.com> writes:
[threads in emacs]
:) There is still the question for which I still have not heard
a good answer--- Why do this?
As this discussion came from the ding list, I take the natural
example. Emacs lock up for a long time when Gnus enters a huge
folder.
If there were support at the language level to start a truly
asynchronous thread Gnus could build the summary buffer in background
and present it to the user when it's finished.
Using callbacks in the "asynchronous" process filters a'la M-x man as
has been suggested won't buy us nothing -- the elisp interpreter is
still synchronous.
I also agree with the opinion that adding thread support at the
language level is easier than making applications take advantage of
threads. But that's a poor excuse for not implementing threads at the
language level.
I agree that we could save some memory with threading vs. multiple
processes, but memory is much cheaper than man hours. We'd have to
overhaul the Lisp system and all the applications to make them
mt-safe, and all without funding? I can't imagine it happening.
Neither do I. The only chance I see this happening is a project
re-targeting Emacs under Guile or some other language that already
have thread support. I think thread support in itself has to little
momentum to gather enough interest.