Re: advice needed for multi-threading patch

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

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

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

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

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

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

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

You mean "each keyboard", right?

> Also, there are tons more problems if you want preemptive
> multithreading... redisplay probably needs work, regex is not
> reentrant, the GC needs a bit more work, you need lisp-level
> locks, etc.

Yes, lots of fun stuff, indeed.

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

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


        Stefan