version 19, a call for discussion, not a request
Peter R. Ham
Actually, it's not version 19, I'm interested in, but
the "perfect emacs".
Specifically, has anyone thought about putting in
multiple elisp threads. 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.
How does the control-g, abort command work? Is it
different from other keystrokes in that it can
interrupt the an elisp thread of control? Can
an elisp thread of control then be resumed again?
Could this be considered the beginnings of
multi-threaded emacs? Ie. a timer could go off
and interuppt an elisp thread and then context
switch to another thread.
This is interesting, but then all of the concurrency
control problems like locking and deadlock come up.
Is there a way to have asynchrony, but insulate the naive
elisp routine writer from this?
Comments?
--
Peter Ham PO Box 3430 (h)(415) 322-4390
MS Computer Science Student Stanford, CA h...@cs.stanford.edu
Stanford University 94309 (o)(415) 723-2067
Jeff Peck
>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.