[coyotos-dev] IDL compatibility

[Charles Landau]

At 10:46 AM -0400 6/19/07, Jonathan S. Shapiro wrote:
>On Mon, 2007-06-18 at 16:56 -0700, Charles Landau wrote:
>>  At 2:15 PM -0400 6/18/07, Jonathan S. Shapiro wrote:
>>  >For interoperability, the thing we most need to watch out for is that
>>  >the name mangling strategies of the respective IDL compilers remain
>>  >compatible.
>>
>>  What's annoying is that capidl generates exception values that are
>>  inconsistent. For example
>>
>>  package coyotos;
>>  exception foo;
>>
>>  and
>>
>>  package capros;
>>  exception foo
>>
>>  generate different values for the exception.
>
>This is not inconsistent. It is *required*. These method declarations
>appear in distinct packages. They are distinct exceptions and must be
>assigned distinct codes.

No, only values in a single chain of inheritance must be distinct. 
This example has completely distinct chains.

>  > Method codes, for some reason, seem to match.
>
>This is a bug, and it is being repaired. The original intent was that
>method codes should be determined cryptographically. The concern was
>that a 32-bit order code lent itself to birthday paradoxes if a
>system-wide total of 2^16 methods were declared (as seemed likely). I
>have subsequently concluded that my concern was excessive, because the
>real issue is 2^16 methods in any single chain of inheritance.

Because only values in a single chain of inheritance must be distinct.

>Cryptographic code points are regrettable because they cannot be
>efficiently demultiplexed. The problem with any *other* method code
>synthesis scheme is that central coordination is required to avoid code
>point collisions.

There are many schemes that could avoid collisions in a single chain 
of inheritance. You could have an easily-demultiplexed method index 
in the low bits, and (only for robustness, in case a method code is 
misused) a hash in the high bits.

>The reason that we did not do this for exceptions is that exceptions are
>cross-cutting. While method names exist in the context of an interface,
>exceptions can propagate widely, and exception names are therefore
>effectively global.

I see. Hmm.

>The current exception code scheme will fail if more
>than 2^16 exceptions come to exist system-wide, and I am of the opinion
>that exception code values should be increased to 64 bits to avoid this.

That would reduce the probability of collision, but not to zero, and 
at a runtime cost.

The way to absolutely guarantee non-collision is to declare all the 
exceptions at one level. Unix's errno.h demostrates that that's 
feasible. cap.idl already declares exceptions that are only used by 
derived interfaces.

They would be declared within the coyotos package (or perhaps 
coyotos.cap), which captures the knowledge that exception codes will 
not propagate between Coyotos and CapROS (just as they won't 
propagate to Unix).

People are still free to declare their own exceptions locally, they 
just can't propagate them with any guarantee of uniqueness.