Re: Patch for fields of `struct buffer'

[Tom Tromey <tromey@redhat.com>]

Tom> What I meant by this is that any proposed change has to come with a plan
Tom> to upgrade the existing body of Emacs Lisp code, not all of which is
Tom> included in Emacs.

Helmut> I think threads are a new feature and it wouldn't surprise me that new
Helmut> code must be written to use that feature.

Yes, I agree, but such code will want to reuse much of the existing
library of Emacs Lisp.

Tom> With locks it is probably possible to do this piecemeal.

Helmut> I think explicit locks put the burden on the programmers.  They must
Helmut> debug/update/fix their programs for a multi-threaded world even if they
Helmut> don't use threads.  Not a pay-as-you-go kind of plan, is it?

No, it is not ideal, but (1) it can work and (2) many important locks
can effectively be hidden, at least on a "you usually do not need to
thhink about it" basis.

Helmut> HTML5 Web Workers avoid shared mutable objects.  Instead
Helmut> of creating a thread with (spawn (lambda () ...)) 
Helmut> we would have something like (worker "task.el").

Helmut> Where "task.el" is a file containing the program that does all the
Helmut> work. A worker starts with an (almost) empty environment and must
Helmut> initialize all needed state from zero.

This seems very impractical to me.

Helmut> In particular if some library is
Helmut> needed it must be loaded explicitly (that's not visible in the parent
Helmut> thread).  A worker can only communicate with other threads via pipes (I
Helmut> think workers exchange Javascript objects in JSON format in HTML5; maybe
Helmut> we would use sexps for Emacs).

A variant of this idea is either to add a `fork' primitive to Emacs (not
portable, more's the pity) or just spawn a headless Emacs with
bidirectional communication.  With the fork approach you could even do
fancy things like let the child inherit and take over some network
connections.

This approach is somewhat heavy, as you say.  Also, I think initializing
the new environment (in the spawn model) is non-trivial.  All those
globals do matter...

I'm actually not sure why this idea isn't more popular.  I think at
least the basic spawn approach could be implemented immediately in lisp.

Tom