Why do I get the feeling that I've opened a can of worms. Okay, here's my $0.02. In order for threading to work with emacs-lisp the following things need to happen. (We're talking relatively long term here, hence the word roadmap.) o The OS First off, the OS itself needs to "support" threads. Most industrial strength OSes do so. Examples, DG/UX, HP/UX, AIX, Linux, Windoze, Sun. o [x]emacs [x]emacs would need to use a threaded library in order to support multiple threads of execution within the same process. gtk/glib would be _one_ solution. Its used extensively in gnome and mozilla. xemacs code would need to be made mt-safe by mutex-locking out critical sections of the code. gtk/glib could provide a new widget set to replace existing ones, but that's another debate. o emacs-lisp the base emacs-lisp would need to provide extended lisp functionality to interface with the low-level threads library. This would probably be a package that provides mutex o emacs-lisp applications Applications like gnus, w3 which can potentially do multiple asynchronous fetches in the background would, probably benefit from an mt emacs-lisp. Issues like how many threads (eg. 1 per newsgroup?) synchronization, mutual exclusion etc would probably be counter-balanced by improvement in performance and functionality. A context switch between two threads in a single process is considerably cheaper than a context switch between two processes. Also, all data except for stack and registers are shared between threads. This makes threading interesting for such apps. _LISP_ code wouldn't magically become mt-safe, it would need to be modified to make it so. One would, of course, have the option to use only a single thread of execution, so existing apps should work with even with mt emacs-lisp. Now now, there's no need for foul language. Go stand in the corner.