Re-writing of Process key issue

Jonathan Adams jonadams@netcom.com
Tue, 7 Apr 1998 01:08:28 -0700 (PDT)


Let me try to restate the problem in a way which will minimize confusion:

1)  There is a domain, which is created by a factory, which needs to be 
able to be passed start keys to other domains *created with the same 
factory*.   The classic case of this is a container class (i.e. KeyKos's 
KID, and EROS's equivalent of the KID, known as KeySet).

2)  The domain can use it's domain creator key to verify that the key is 
indeed a start key to a domain created with the same factory.  Because of 
this, the domain can trust the code of the other domain, since it is the 
same code it is running.

3)  The domain needs to be able to communicate with the other domain by 
CALLing a start key to it (not necessarily the passed in key -- the 
domain could create a new start key with the Domain key returned from the 
Domain Creator).  The problem is that if the key is a start key to the 
domain itself, this is an action which will have undesired effects.  
(i.e. in the current EROS implementation, AFAIK, it will cause the domain 
to wait indefinately.  KeyKos will invoke the domain's keeper)

4)  What the domain would like, then, is an easy way to check if the 
passed in key is a start key to itself.  The current best way of doing 
this (in EROS, at least) is using DISCRIM to compare the domain's 
own Domain key to the Domain key returned from amplifying the start key 
with the Domain Creator.

The issue does not seem to be an often encountered one, but I ran across 
it in reviewing the implementation of the EROS KeySet.

One piece of the issue I do not fully grasp is the difference in 
philosophies between KeyKos and EROS.  In KeyKos, Sense keys are 
restricted and DISCRIM has open access, while in EROS, Discrim is 
restricted and Sense keys can be created by anyone.

This case can certainly be solved in other ways than with Discrim -- for 
instance, if the EROS Process key followed it's description in the ObRef, 
it could be done by swapping in DK(0) for the schedule key of the other 
process, then swapping it back.  The first operation would fail with  
"OC_Dom_Returnee" if the domain was the invoking domain. (This is, of 
course, a possibly dangerous action on the other domain if someone is 
mucking with it's schedule key)

In any case, I hope this clears up some of the confusion surrounding my 
inadaquate presentation of the issue.

Thanks,
- Jonathan Adams