Re: advice needed for multi-threading patch

[Tom Tromey]

>>>>> "Stefan" == Stefan Monnier <address@hidden> writes:

Tom> * Many, but not all, of the 9 kinds of variables that Emacs implements
Tom> work properly with threads.  In particular, working ones are
Tom> defvaralias, objfwd, and ordinary.  These all should do the right
Tom> thing in all cases.  Buffer-local and buffer objfwd mostly work,
Tom> because we do buffer locking.  (However, I think make-local-variable
Tom> doesn't work properly with let-binding and multiple threads.)  Not
Tom> working on intfwd, boolfwd, keyboard-local and frame-local.

Stefan> How do you handle objfwd objects?  Do you swap them in&out during
Stefan> context switches?

We have a script to edit the Emacs source.  In the end all DEFUN_LISP
variables are defined like:

#define Vafter_change_functions *find_variable_location 
(&impl_Vafter_change_functions)

Then, find_variable_location understands Lisp_ThreadLocal binding.
A Lisp_ThreadLocal is put into an impl_V* by specbind.

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

We don't swap anything in and out during a context switch.  I've tried
to make all the decisions with an eye on the long term: preemptive
threading.  Ultimately I'd like to get rid of the global lock and have
all threads run free.

Tom> * Buffer locking is actually quite a pain.
Tom> If you have a background thread locking some buffer, you can't switch
Tom> to that buffer.  Emacs will just pause.  I don't think we allow
Tom> interrupting a lock acquisition (clearly a bug).

Stefan> Yes, we may have to relax the locking somehow.  E.g. we should clearly
Stefan> allow to display a buffer in any window, if the buffer is "locked" by
Stefan> a thread.  I.e. things like switch-to-buffer should not take the
Stefan> buffer's lock.

Stefan> Of course, if the buffer is locked by a thread, we also need to be
Stefan> careful what we do if the user then types a command in it (should we
Stefan> wait for the thread to yield or should we signal an erreur?)

Giuseppe has some code to let a thread acquire a buffer without locking.
But, this is done in an unsafe way; I think it is just a hack to let him
experiment with Gnus a bit.

Right now when a thread yields it does not release its buffer lock.
The only way to do that is to set-buffer to another buffer.

One way forward would be to work out the semantics properly, and
eliminate buffer locking.  Some of the semantics seems tricky.  And, the
work itself is hard, because it means adding tons of accessor macros and
then updating a lot of source code to use them.  (I did this, once, for
a lot of Emacs, thinking to implement a software write barrier.  It is
really quite painful.)

Tom> * Giuseppe implemented minibuffer exclusion.  But really the keyboard
Tom> should only be available to one thread at a time.

Stefan> You mean "each keyboard", right?

Yes.

Locking a keyboard will probably have strange effects.  There are some
things here that I have not thought through; like, what is the right
behavior of debug-on-error?  Under what conditions would the main thread
ever release the keyboard?

Tom> Sometimes I wonder whether it would be better to just fork a second
Tom> emacs and communicate with it using pipes + princ + read.  This uses
Tom> more memory but the implementation would be a lot simpler and (I think)
Tom> it would suffice for the one case that seems most important: Gnus.

Stefan> But you can already do that right now, so it's a different "solution".

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

Tom