Re: GC leak?

dhruva writes: 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. Maybe. IMHO there are far more fundamental problems with Emacs Lisp as a general purpose platform. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta