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

Kevin Reid 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  
seedVat/2.

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  
other suggestions.


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