[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Concurrent programming coming to JavaScript
Allan gives a very nice summary of the differences between the Actor model
and CSP - but there are also very many things in common - or at least common
desires. I found the article in http://en.wikipedia.org/wiki/Actor_model
VERY thought provoking.
Maybe we are less out-on-a-limb than we think (?)
I need to follow-up some of the leads from this article, and other places.
The Actor model has not been much mentioned in WoTUG (CPA) [as far as I can
remember] - is there a good reason for this or should we be looking at it
more seriously?
Barry.
Dr Barry M. Cook, BSc, PhD, CEng, MBCS, CITP, MIEEE
CTO,
4Links Limited,
The Mansion,
Bletchley Park,
MK3 6ZP,
UK.
----- Original Message -----
From: "Allan McInnes" <amcinnes@xxxxxxxxxx>
To: <occam-com@xxxxxxxxxx>
Cc: <java-threads@xxxxxxxxxx>
Sent: Thursday, February 22, 2007 3:09 AM
Subject: Re: Concurrent programming coming to JavaScript
It's probably worth noting that Will Clinger (mentioned in the extract of
Brendan's blog) did a bunch of work on the Actor model of concurrency. So
it's
possible that's the direction that Javascript will end up going for
concurrency. The Actor model shares a lot of ideas with CSP, but also has
a few
key differences, e.g. asynchronous rather than rendezvous communications,
and
message delivery based on the identity of the receiver rather than via
channels
(Erlang, for those familiar with it, uses a message-passing approach along
the
lines of the Actor model).
Of course, it's pretty straightforward to build a CSP-like channel-based
rendezvous messaging system on top of an Actor-style system, so Tom's idea
of a
CSP library should be feasible even if Javascript does take the Actor
route
instead of the CSP one. Either approach would be a vast improvement over
threads with shared state.
Allan
Quoting Tom Locke <tom@xxxxxxxxxxxxx>:
Hi All,
I find the following to be of extreme importance to us CSP lovers:
Brendan "JavaScript" Eich wants to include *useable* language-level
support for concurrency into JavaScript 3
Key quotes:
A requirement for JS3 (along with hygienic macros) is to do
something along these more implicit lines of concurrency support. In
all the fast yet maintainable MT systems I've built or worked on, the
key idea (which Will Clinger stated clearly to me over lunch last
fall) is to separate the mutable unshared data from the immutable
shared data. Do that well, with language and VM support, and threads
become what they should be: not an abstraction violator from hell,
but a scaling device that can be composed with existing abstractions.
So here's a promise about threads ... JS3 will be ready for the
multicore desktop workload.
Link: http://weblogs.mozillazine.org/roadmap/archives/2007/02/
threads_suck.html
There is a growing belief that Ecmascript / JavaScript is about to
become The Next Big Language. Static typing is being added, as well
as other "in the large" features. Performance is becoming competitive
with Java. I think it's already the most widely known language...
Some of you heavy-hitters really need to start up a dialogue with Eich.
Of course the future is always murky, but there's a pretty real
possibility that this is *the* opportunity to take the CSP ideas we
love mainstream. An opportunity such that has never existed and may
never again.
At *least* it might be possible to steer things such that the
primitives can support fine-grained, high performance CSP via a library.
Peter - remember your CSP workshops at Sun where you convinced (IIRC)
everyone except Gosling? Time for a re-run at the Mozilla foundation!
These open-source types are much cuddlier than corporate lackeys
y'know :-)
Time to act!
Tom
--
Allan McInnes <amcinnes@xxxxxxxxxx>
PhD Candidate
Dept. of Electrical and Computer Engineering
Utah State University