Re: Concurrent programming coming to JavaScript

[Allan McInnes <amcinnes@xxxxxxxxxx>]

I know from online exchanges with Carl Hewitt (the driving force behind much the
Actor model work) that he was aware of the work being done on CCS/CSP.
Similarly, Will Clinger's PhD thesis on Actor model semantics mentions the
original CACM paper on CSP. Going the other way, I gather that Robin Milner (at
least) was aware of what Hewitt was up to as well, since Milner's Turing Award
lecture references the Actor model as part of the inspiration for the
pi-calculus.

Despite the fact that both groups seem to have been at least somewhat aware
of the other, for some reason the two communities appear to have grown quite
separately. Part of that can perhaps be attributed to some fundamental
differences of opinion over appropriate primitives: my impression is that
Hewitt strongly favored named agents with asynchronous communications, while
Milner and Hoare were more in favour of anonymous agents with rendezvous
communications - the latter lending itself much more easily to algebraic
analysis. The result was that theoretical work in one community was less
likely to be applicable to problems faced by the other community.

That said, I agree with Barry that the CPA community and the Actor community
definitely share common aspirations and common concerns. It'd be good to see
greater cooperation between the two groups in advocating share-nothing,
message-passing concurrency.

Allan



Quoting Barry Cook <Barry@xxxxxxxxxxxx>:

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


-- 
Allan McInnes <amcinnes@xxxxxxxxxx>
PhD Candidate
Dept. of Electrical and Computer Engineering
Utah State University

----- End forwarded message -----


-- 
Allan McInnes <amcinnes@xxxxxxxxxx>
PhD Candidate
Dept. of Electrical and Computer Engineering
Utah State University