Re-writing of Process key issue

[Landau, Charles]

I'm catching up on some old mail.

> The domain needs to be able to communicate with the other domain ...
Granted.
> by CALLing a start key to it
Not so fast. The problem you mention is only one of the problems with this
approach. There is a larger deadlock issue. Suppose two domains try to do
this to each other at the same time. The implementation of KeySet described
by Jonathan Adams appears to suffer from this bug. 

When you solve the problem of multiple domains in deadly embrace, you will
also have solved the problem of a single domain in deadlock with itself. You
don't need to detect this case separately. 

I think it at least one case we solved this by storing in a fixed key
register of each domain a key that refers to the information about this
domain that other domains need to access. A key register can be atomically
updated, so the synchronization problem can be solved. Given the domain key
you got from the domain creator, you can fetch this key even from yourself.
That information can include a unique ID for each domain if you really want
to know who is who. 


> -----Original Message-----
> From:	Jonathan Adams [SMTP:jonadams@netcom.com]
> Sent:	Tuesday, April 07, 1998 1:08 AM
> To:	eros-arch@eros.cis.upenn.edu
> Subject:	Re-writing of Process key issue
> 
> 
> 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
>