Re: advice needed for multi-threading patch

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

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)

Oh, right, I remember now, sorry.

> 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.

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

> 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.

That was the motivation for my question, indeed.

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

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

> One way forward would be to work out the semantics properly, and
> eliminate buffer locking.

Yes, although the result of this may end up requiring some form of
buffer-locking, still.

> Some of the semantics seems tricky.

Oh, yes.

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?

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

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

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


        Stefan