🚀 go-pugleaf

>If I write a particularly long running elisp program, then it ties up my emacs
>session and doesn't even give me an up to date screen to look at. Anyone
>thought of ways to get around this.

 Perhaps you should use Unix!  spawn a subjob (running emacs if necessary)
and pipe the current buffer to it, which it will process as a filter and return!
You see, you already have multitasking on your desktop!

>Specifically, has anyone thought about putting in multiple elisp threads. 

See if you can find the latest version of Sun Common Lisp with the SPE 1.1
(Symbolic Programming Environment).  We put a Multithreaded, Multiwindow,
Emacs (mostly GNU compatible) into that system.

 When the real multi-window emacs is available, it would not be difficult to
mixin, for example, the Sun LWP library to handle thread context switching,
but from recent experience with `threadifying' Scheme, i guarentee it will
be non-trivial, with lots of "gotchas".
  Multithreading lisp/emacs is more complex than you may first imagine.  
(also consider the effects on compacting GC!).

  Threads are a way to bundle and save the context of a process while it is
inactive (preempted or waiting for IO).  [Fortunately, most of the context
for editing is already bundled in the "buffer" structure]

>This is interesting, but then all of the concurrency 
>control problems like locking and deadlock come up.

In the SPE Emacs, locking is seldom done, since it is infrequent that 
two threads would simultaneously be modifying a single buffer.  If
they are, the results may be conceptually indeterminate anyway.
Yes, it is an issue, but not the first or biggest one.

>Is there a way to have asynchrony, but insulate the naive
>elisp routine writer from this?

 For many command functions is it possible to ignore threads, 
but for those that create or switch windows or buffers, the writer
must specify the relationship of the new entity: If you want to edit
buffer "foo", should the current thread switch to that buffer? in which
window? should the window already editing "foo" (handled by another thread) 
be given the keyboard focus? should a new thread be started? If some other
thread has modified a buffer, what does "Undo" in this thread mean?
Is there a thread per window? a thread per buffer? per user? Is there
only one idle thread? background threads that complete die, the One
thread handles all user input?  then how do i indicate i want async
versus synchronous execution of this command? what if the background-async
thread invokes recursive-edit? or otherwise needs keyboard editing support?

 The technical issues of MP programming are just the Tip of the Iceberg,
the number of  User Interface and programmer model issues is overwhelming.