unknown
1970-01-01 00:00:00 UTC
<div><br></div><div>As context for those new to this thread, earlier I wrot=
e=A0</div><div><br></div></div><blockquote style=3D"margin:0 0 0 40px;borde=
r:none;padding:0px"><div class=3D"gmail_quote">
<div><span style=3D"font-family:arial, sans-serif;font-size:13px;background=
-color:rgb(255, 255, 255)">[...] Doug Barnes first created Original-E, by s=
hoehorning Joule-inspired concurrency onto a Java base in an intense two we=
ek efforts driven by a business panic, after a contractual dispute between =
Agorics (creator, provider, and supporter of Joule, where I was) and Electr=
ic Communities (using Joule to create a decentralized secure virtual realit=
y, where Doug Barnes was). I only joined E.C. a year or so later, in 1995, =
whereupon I took over leadership of the Original-E effort.</span></div>
</div></blockquote><div class=3D"gmail_quote"><div><br></div><div>The signi=
ficance of that step cannot be underestimated. Prior to this, all the Actor=
s and concurrent logic work that I was aware of assumed that, to get a lang=
uage with a sensible concurrency control model (e.g., actors or concurrent =
logic programming), you had to start with concurrency. After all, the previ=
ous attempts we were aware of adding concurrency to a sequential language b=
ase, including Multilisp btw, but including the earlier efforts of geniuses=
like Dijkstra (semaphores) and Hoare (monitors), all ended up making the s=
hared state concurrency mistake, i.e., shared memory multithreading with fi=
ne grained locking. For the Vulcaneers, this view had been reinforced at PA=
RC, as the other concurrency crowd there was developing Cedar, an outgrowth=
of Mesa, which proceeded to inspire the Modula-Ns, where very smart people=
made this mistake everywhere. (Hoare's CSP and ccam=A0avoided this mis=
take, but at such a severe loss of expressiveness that we did not take it s=
eriously.)</div>
<div><br></div><div>Looking at the results of Doug Barnes' two week eff=
ort, it was clear that there was never any necessary conflict all along, bu=
t none of us had been able to see it. The Joule concurrency constructs, gra=
fted onto a sequential Java base, did not push that base towards=A0shared s=
tate concurrency. However, even by the time I arrived at E.C., the Joule-li=
ke concurrency that Doug added was not quarantined from Java's shared s=
tate concurrency, leaving a mess. (I would argue that Scala today makes the=
same mistake.)</div>
<div><br></div><div>At E.C., Danfuzz Bornstein and I brought vats to Origin=
al-E, finally fully separating Original-E's Joule-like concurrency from=
the hazards of Java's shared state concurrency. In some ways the Origi=
nal-E vat was based on the Joule "tank", serving as a unit of pre=
emptive termination and transparent distribution. But this didn't help =
regarding concurrency models, as a Joule tank, like an Actors worker, was s=
till pervasively concurrent internally. Instead, I realized that an Origina=
l-E vat was, in this sense, like a single big highly-multi-faceted single J=
oule actor, where each locally exported object acts as a distinct facet of =
the vat. In this context, Joule's inner send became conventional LIFO i=
mmediate call-return, which any object within a vat could only immediate-ca=
ll other objects within the same vat. Whereas anyone could do an eventual s=
end to a facet of a vat, i.e., any object within a vat they had a reference=
to, which would only queue up on the end of the queue. The two-ended deque=
ue nature of Original-E's stack + pending deliver queue is in this sens=
e a direct reflection of the inner-send fix that Dean contributed to that f=
irst Vulcan paper.</div>
<div><br></div><div>On Sun, Jun 12, 2011 at 10:48 AM, Dean Tribble=A0<span =
dir=3D"ltr"><<a href=3D"mailto:***@e-dean.com" target=3D"_blank">tri=
***@e-dean.com</a>></span>=A0wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.=
8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-=
style:solid;padding-left:1ex">
[...]=A0A straightforward interpretation of "coarse-grained actor"=
; would have multiple capabilities into the shared state of the "actor=
".=A0The important addition is that, in a vat, the set of capabilities=
=A0available from outside the vat=A0to the state in the vat can change dyna=
mically.=A0Thus, I think of is as a worthy alternative to fine-grained acto=
rs models.=A0</blockquote>
</div><div><br></div><div>Exactly. The hard part for me of getting from Jou=
le to this repair of Original-E was to see a local heap of sequential objec=
ts as a large multi-faceted actor, and to realize that exporting a previous=
ly unexported object from within this local heap was like *dynamically* add=
ing a facet to a Joule actor, which was not possible in Joule. Once I took =
on this shift of perspective, much of the rest followed naturally.</div>
<div><br></div><div>The mechanics of Original-E references was still proble=
matic, as Joule's multichannels did not co-exist with sequentiality all=
that smoothly, especially regarding problem reporting. In 1998, when Chip =
Morningstar (cc'ed) and I derived E from Original-E, I returned to many=
aspects of Xanadu's promise system that Joule had left behind. Sometim=
e in early 1998, when I sketched the eight hand drawn pages scanned in at &=
lt;<a href=3D"http://erights.org/e/semantics.html" target=3D"_blank">http:/=
/erights.org/e/semantics.html</a>> all this came together into the refer=
ence mechanics of modern E.</div>
<div><br></div></div><font color=3D"#888888">-- <br>=A0 =A0 Cheers,<br>=A0 =
=A0 --MarkM<br>
</font><br>_______________________________________________<br>
e-lang mailing list<br>
<a href=3D"mailto:e-***@mail.eros-os.org">e-***@mail.eros-os.org</a><br>
<a href=3D"http://www.eros-os.org/mailman/listinfo/e-lang" target=3D"_blank=
">http://www.eros-os.org/mailman/listinfo/e-lang</a><br>
<br></blockquote></div><br></div></div></div>
--20cf300514b220300c04a58a63e7--
e=A0</div><div><br></div></div><blockquote style=3D"margin:0 0 0 40px;borde=
r:none;padding:0px"><div class=3D"gmail_quote">
<div><span style=3D"font-family:arial, sans-serif;font-size:13px;background=
-color:rgb(255, 255, 255)">[...] Doug Barnes first created Original-E, by s=
hoehorning Joule-inspired concurrency onto a Java base in an intense two we=
ek efforts driven by a business panic, after a contractual dispute between =
Agorics (creator, provider, and supporter of Joule, where I was) and Electr=
ic Communities (using Joule to create a decentralized secure virtual realit=
y, where Doug Barnes was). I only joined E.C. a year or so later, in 1995, =
whereupon I took over leadership of the Original-E effort.</span></div>
</div></blockquote><div class=3D"gmail_quote"><div><br></div><div>The signi=
ficance of that step cannot be underestimated. Prior to this, all the Actor=
s and concurrent logic work that I was aware of assumed that, to get a lang=
uage with a sensible concurrency control model (e.g., actors or concurrent =
logic programming), you had to start with concurrency. After all, the previ=
ous attempts we were aware of adding concurrency to a sequential language b=
ase, including Multilisp btw, but including the earlier efforts of geniuses=
like Dijkstra (semaphores) and Hoare (monitors), all ended up making the s=
hared state concurrency mistake, i.e., shared memory multithreading with fi=
ne grained locking. For the Vulcaneers, this view had been reinforced at PA=
RC, as the other concurrency crowd there was developing Cedar, an outgrowth=
of Mesa, which proceeded to inspire the Modula-Ns, where very smart people=
made this mistake everywhere. (Hoare's CSP and ccam=A0avoided this mis=
take, but at such a severe loss of expressiveness that we did not take it s=
eriously.)</div>
<div><br></div><div>Looking at the results of Doug Barnes' two week eff=
ort, it was clear that there was never any necessary conflict all along, bu=
t none of us had been able to see it. The Joule concurrency constructs, gra=
fted onto a sequential Java base, did not push that base towards=A0shared s=
tate concurrency. However, even by the time I arrived at E.C., the Joule-li=
ke concurrency that Doug added was not quarantined from Java's shared s=
tate concurrency, leaving a mess. (I would argue that Scala today makes the=
same mistake.)</div>
<div><br></div><div>At E.C., Danfuzz Bornstein and I brought vats to Origin=
al-E, finally fully separating Original-E's Joule-like concurrency from=
the hazards of Java's shared state concurrency. In some ways the Origi=
nal-E vat was based on the Joule "tank", serving as a unit of pre=
emptive termination and transparent distribution. But this didn't help =
regarding concurrency models, as a Joule tank, like an Actors worker, was s=
till pervasively concurrent internally. Instead, I realized that an Origina=
l-E vat was, in this sense, like a single big highly-multi-faceted single J=
oule actor, where each locally exported object acts as a distinct facet of =
the vat. In this context, Joule's inner send became conventional LIFO i=
mmediate call-return, which any object within a vat could only immediate-ca=
ll other objects within the same vat. Whereas anyone could do an eventual s=
end to a facet of a vat, i.e., any object within a vat they had a reference=
to, which would only queue up on the end of the queue. The two-ended deque=
ue nature of Original-E's stack + pending deliver queue is in this sens=
e a direct reflection of the inner-send fix that Dean contributed to that f=
irst Vulcan paper.</div>
<div><br></div><div>On Sun, Jun 12, 2011 at 10:48 AM, Dean Tribble=A0<span =
dir=3D"ltr"><<a href=3D"mailto:***@e-dean.com" target=3D"_blank">tri=
***@e-dean.com</a>></span>=A0wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.=
8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-=
style:solid;padding-left:1ex">
[...]=A0A straightforward interpretation of "coarse-grained actor"=
; would have multiple capabilities into the shared state of the "actor=
".=A0The important addition is that, in a vat, the set of capabilities=
=A0available from outside the vat=A0to the state in the vat can change dyna=
mically.=A0Thus, I think of is as a worthy alternative to fine-grained acto=
rs models.=A0</blockquote>
</div><div><br></div><div>Exactly. The hard part for me of getting from Jou=
le to this repair of Original-E was to see a local heap of sequential objec=
ts as a large multi-faceted actor, and to realize that exporting a previous=
ly unexported object from within this local heap was like *dynamically* add=
ing a facet to a Joule actor, which was not possible in Joule. Once I took =
on this shift of perspective, much of the rest followed naturally.</div>
<div><br></div><div>The mechanics of Original-E references was still proble=
matic, as Joule's multichannels did not co-exist with sequentiality all=
that smoothly, especially regarding problem reporting. In 1998, when Chip =
Morningstar (cc'ed) and I derived E from Original-E, I returned to many=
aspects of Xanadu's promise system that Joule had left behind. Sometim=
e in early 1998, when I sketched the eight hand drawn pages scanned in at &=
lt;<a href=3D"http://erights.org/e/semantics.html" target=3D"_blank">http:/=
/erights.org/e/semantics.html</a>> all this came together into the refer=
ence mechanics of modern E.</div>
<div><br></div></div><font color=3D"#888888">-- <br>=A0 =A0 Cheers,<br>=A0 =
=A0 --MarkM<br>
</font><br>_______________________________________________<br>
e-lang mailing list<br>
<a href=3D"mailto:e-***@mail.eros-os.org">e-***@mail.eros-os.org</a><br>
<a href=3D"http://www.eros-os.org/mailman/listinfo/e-lang" target=3D"_blank=
">http://www.eros-os.org/mailman/listinfo/e-lang</a><br>
<br></blockquote></div><br></div></div></div>
--20cf300514b220300c04a58a63e7--