GC leak?

[Stephen J. Turnbull]

dhruva writes:

 > Are there any plans for having a multi-threaded XEmacs?

No; nobody with the ability to do it has done anything resembling
suggesting that they might try.  Suggestions (backed by kilo-man-
hours) welcome, of course.  Also, Emacs Lisp might as well have been
designed to to prevent multithreading.  In general, multithreading of
languages like Lisp is very difficult.  I've been following Python for
years and they still don't have an alternative to the Global
Interpreter Lock AFAIK.  So I expect thread support to be one
criterion in refactoring to replace the Lisp engine en bloc; it won't
be done by itself.

It would certainly be possible to hand off some operations like
reading files to a separate thread, as long as they don't call Lisp.
But AFAIK reading files, even at gigabyte scale, is not what takes so
much time.  It's things like font-locking and other Lisp activity.
Also, in general you have the problem that *users* of Emacs Lisp are
generally single-threading.  If you type C-x C-f gigabyte-log-file
RET, you are very likely to block until the buffer comes up.  A much
better scheme would be to do block reads on demand, so the user can
start reading or editing as soon as they've seen the first 1MB.

 > Well, with such support, XEmacs can become a good general purpose
 > programmable engine!

Maybe.  IMHO there are far more fundamental problems with Emacs Lisp
as a general purpose platform.