Re: advice needed for multi-threading patch

[Tom Tromey]

Tom> This works great as long as the C code follows lispy rules.  However, I
Tom> don't think that is always the case -- there are places doing direct
Tom> assignment to some of these variables where, really, a per-thread
Tom> assignment is meant.

Stefan> I'm not sure what you mean.  Are you still talking about objfwd
Stefan> variables?

Yeah.  What I meant here is that specbind has a little extra code in it
to install a Lisp_ThreadLocal object when needed.  So, if the C code
uses specbind to do let-like binding, everything will work fine.  If the
C code does not do this, then things will break.

For example, I am not certain that Vquit_flag is handled in a "safe"
way.  It is directly assigned to in a number of places, but those
assignments should probably be thread-local.  (This isn't the greatest
example, maybe, because Vquit_flag is also bound up in keyboard locking
and maybe other issues.)

Tom> Right now when a thread yields it does not release its buffer lock.

Stefan> I think it should, unless some of the buffer-local variables are
Stefan> let-bound by the thread.

I've been thinking about this a bit.  It is trickier than it seems,
because a thread can actually have let-bindings for buffer-locals from
multiple buffers at the same time.  There's an example of this in the
elisp manual.  (This is also an area the threading code does not handle
well yet.)

I think this means it does not suffice to keep a simple per-thread count
of buffer-local bindings.

While thinking about this I realized that (I think) the current code
does the wrong thing if one thread let-binds a variable and then another
thread calls make-variable-buffer-local on it.

Stefan> Maybe another way to look at all these problems is to take an
Stefan> "agent" point of view: rather than threads moving around, we
Stefan> could consider each keyboard and each buffer as an active object
Stefan> (i.e. with its own thread), which communicate among each other.
Stefan> I.e. a buffer-thread never leaves its buffer, instead it does an
Stefan> RPC to another buffer-thread, or to a keyboard-thread, ...

I had considered the agent model -- that, plus a discussion on irc, is
actually what lead me to ask about running a second Emacs as a
subprocess.

It is hard for me to see how this could be done in a compatible way.
Right now elisp operates with few constraints; an elisp program can call
select-frame, which seems to imply that per-frame or per-keyboard
threads can't be done.

Tom> Yeah.  I just wonder why nobody has done it and whether it would not be
Tom> a better approach.

Stefan> IIUC people do it all the time, tho not with another Emacs
Stefan> process: with an hexl process, a shell process, an openssl
Stefan> process, ...  Emacs currently is not very good at using
Stefan> stdin/stdout so running an inferior Emacs process is poorly
Stefan> supported.

If I were doing it "for real" I might consider coming up with a
higher-bandwidth way to transfer an entire buffer between processes.
But, a princ/read approach could be done without modifying Emacs, by
having the parent Emacs make a server socket, and then passing the port
number to the subprocess as an argument.  This avoids the stdin/stdout
difficulties.

One thing that would help me is having a concrete idea of what subset of
features would make this work be actually useful.  I mostly implemented
it because it was cool, and because Giuseppe's initial patch convinced
me that it was possible (before that I'd written it off as totally
impractical).  Now that a proof of concept works it would be nice to
have a concrete goal.

Tom