[e-lang] Bug: seedVat/2 and similar are confusing
kpreid at mac.com
Sun Jan 14 18:21:14 CST 2007
On Jan 14, 2007, at 15:13, Mark S. Miller wrote:
> 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?
> 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.
Now that I understand the problem, my first inclination was to
declare this Not A Bug and add warnings to the documentation for
However, making multiple identities in a single vat is not something
that should need to be done often, though it should be possible.
Proposal: keep seedVat/2, so that someone trying to do this
deliberately doesn't need to duplicate the code in seedVatAuthor, but
rename it to something that makes it clear that it's an unusual
operation. What comes to mind is "reseedVat", but I'd like to hear
As a separate item: the "virtualize" naming bothers me. It seems to
me that the 'virtual' version is nearly always what the programmer
wants, rather than using the peculiar boot-comm system, and that it's
not particularly intuitive what 'virtualize' means in this context.
I have committed changes to pass-by-construction.updoc to test the
'near on receipt' case correctly.
Kevin Reid <http://homepage.mac.com/kpreid/>
More information about the e-lang