[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch for fields of `struct buffer'

From: Helmut Eller
Subject: Re: Patch for fields of `struct buffer'
Date: Tue, 08 Feb 2011 18:57:43 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

* Tom Tromey [2011-02-08 16:26] writes:

>>>>>> "Helmut" == Helmut Eller <address@hidden> writes:
> Helmut> Well, no mutable objects could be shared, which is quite different 
> from
> Helmut> a lock; especially the case when somebody forgets to use the lock.
> Tom> I am interested in reasoned arguments, grounded in real Emacs code, to
> Tom> the contrary for either STM or CSP.
> Helmut> With some hand-waving, the current way to deal with external processes
> Helmut> can be seen as form of CSP.  Otherwise I'd say current Emacs code
> Helmut> neither uses STM nor CSP nor locks, which makes it hard to meet your
> Helmut> request.
> What I meant by this is that any proposed change has to come with a plan
> to upgrade the existing body of Emacs Lisp code, not all of which is
> included in Emacs.

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

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

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

> I don't know how to do it for CSP, and for STM the C side seems much too
> hard to contemplate.
> Likewise, I think sharing mutable objects is inevitable given the way
> Emacs Lisp is already written.

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

Where "task.el" is a file containing the program that does all the
work. A worker starts with an (almost) empty environment and must
initialize all needed state from zero.  In particular if some library is
needed it must be loaded explicitly (that's not visible in the parent
thread).  A worker can only communicate with other threads via pipes (I
think workers exchange Javascript objects in JSON format in HTML5; maybe
we would use sexps for Emacs).

This is certainly more heavy weight and probably has its own set of
problems but it obviously works without shared mutable state.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]