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