[e-lang] Bug: seedVat/2 and similar are confusing

Mark S. Miller markm at cs.jhu.edu
Sun Jan 14 14:13:00 CST 2007


The following is now bug 
<https://sourceforge.net/tracker/index.php?func=detail&aid=1635342&group_id=75274&atid=551529>.
The full text of the version of pass-by-construction.updoc which manifests the 
bug is uploaded into the bug report, but will not be committed or released.

Should we fix this by deprecating those elements of the current API that lead 
one into this confusion, i.e., all seedVat-like functions in which an existing 
vat is passed back in as an argument?

Note that the "vsv" below is a virtualized[*] seedVat function.

---------------------
Mysterious behavior reported by Kevin Reid, as represented by the following 
text added to his pass-by-construction.updoc:

Odd case: maker is near only on receipt

     ? def otherMaker := vsv(vat, "fn { def oddFar {} }")
     # value: <Promise>

     ? def otherCall := vsv(vat, "fn r,v,a { E.call(r,v,a) }")
     # value: <Promise>

     ? interp.waitAtTop(otherCall)
     ? [otherMaker, otherCall]
     # value: [<Far ref>, <Far ref>]

     ? def r := interp.waitAtTop(
     >   other <- (
     >     def oddNear implements pbc {
     >       to __optUncall() {
     >         return [otherMaker, "run", []] } }))
     # value: <Remote Promise>

     ? r
     # value: <Far ref>

     ? def t := interp.waitAtTop(otherCall <- (E, "toString", r)); null
     ? t
     # value: "<oddFar>"


Te actual problem is that seedVat/2, where an explicit vat is provided, and 
similar functions such as virtualized[*] seedVat/2 and makeServer/2, are 
confusing and accident prone, regarding what the programmer would naturally 
consider to be the "same" vat.

In all these cases, the vat is only the same as far as the boot-comm system is 
concerned. In each case, the string is evaluated using the context of a new 
privilegedScope created in that vat. Since each such privilegedScope has its 
own introducer, are the CapTP level, each call to such a function creates a 
new CapTP identity, even though the same "vat" argument is being passed back in.


[*] By "virtualized seedVat/2", we mean the seedVat/2 function returned by 
seedVatAuthor#virtualize

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM


More information about the e-lang mailing list