[coyotos-dev] Some comments on Coyotos Microkernel Specification

[David Hopwood]

Christopher Nelson wrote:
>David Hopwood wrote:
>>On the particular application being discussed here, I agree with
>>Constantine Plotnikov's argument:
>>
>># I think that qualified name is better approach because it can
>># ensure that there are no collisions between well done
>># interface definitions. In Java such approach worked quite
>># well. There is usually no conflict between namespaces of
>># _useful_ libraries. In your approach, if there is a problem,
>># the problem is forever and it is unfixable
>>
>>[without breaking compatibility for that type/interface]
>>
>># and it is not possible to determine in advance whether there is a
>># conflict. Note: there is usually no problem with distinguishing garbage
>># object from garbage object.
>>#
>># Also using qualified name as type identifier gives an immediate hint
>># where to locate information about service and what service does. Integer
>># does not provide any of this information. The alleged type can be printed
>># by the directory listing program for example. The type names are much
>># better for sorting and [searching?].
>>
>>Note that strings used as type identifiers can easily be bounded
>>length (say, < 512 characters or bytes) without losing their human-factors
>>advantages.
> 
> My understanding of the problem is that a string is [not] bounded in the
> same way that, say, an integer is bounded.  On a given platform a [machine]
> integer is N bits.  Period.  No more, no less.  No operation is needed to
> find out how long the integer is because it's known at compile time.
> 
> Consider too the ramifications of comparison operators.  What is the
> performance difference between:
> 
> 5 < 6 ? 0 : 1
> strcmp(s1,s2) ? : 0 : 1  

Comparing "interned" strings [*] is a simple pointer comparison. A pointer
to an interned string is a small fixed length. So there is no performance
difference, and no significant "difficulty in keeping track of" such strings.

To address the argument Shap made about versioning: each version of each
interface must have a fully qualified string name in order for it to be
referred to unambiguously by an IDL definition.

This is the name that should also be used (logically, ignoring compression and
encoding issues) when referring to the interface version in other contexts,
including wire protocols.

Note that it is not feasible to use as an identifier for an interface version
a cryptographic hash of its IDL definition and all definitions on which it
is dependent, because there can be cyclic dependencies. So there *must* be an
identifier for each interface version that is separate from its IDL definition,
and this identifier might as well be a human-readable name.


[*] Java terminology for "hash consing" of strings: each system maintains an
    "interned string table" which is a 1-1 mapping relating pointers to strings.
    Every new string is looked up in the table, and added if it is not already
    present. Note that it is still possible to garbage collect table entries.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>