Re: multi-threaded Emacs

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Anyway, a non-preemptive threading will not give any real parallelism

I admire your enthusiasm, but I think that if you don't want to get
burned, you should set yourself more realistic goals.  Parallelism is
going to require a very large amount of work.  We'll hopefully get there
at some point, but there are many useful steps to have to take before we
get there.

> and it will require more changes in the Elisp packages to use threads as
> they will need to say explicitly when give the control to another
> thread.

Actually no.  There are already `yield' points in Elisp: basically
whenever we wait for a process or wait for user input.  So there's no
need to change too many things before we can start using cooperative
threading (another name for "a single thread active at a time").

It's still useful because it introduces the multiple stacks, which will
allow for example using one thread per terminal, so that doing M-x in
one terminal will not screw over the other terminals.  Also it'll make
asynchronous execution easier.  So it'll be useful to Elisp packages.

It'll also be a useful implementation step on the way to parallelism,
since it will make us deal with multiple stacks, dynamic scoping, ...

We will already be able to try to tackle things like: be able to edit
a file in a window while Gnus is waiting for your newsserver to send the
list of new groups.

Then we can think of making concurrency more fine-grained to try and get
parallelism.

> accesses with a lock/unlock, but how many times does it happen to change
> the value of a global variable?

*All* the time.  Elisp is really terrible in this respect.  Remember:
all buffers are part of the "global state", same for pretty much all
objects.  Currently even "local variables" are actually global,
tho admittedly, fixing dynamic-scoping will/should improve this part.


        Stefan