[coyotos-dev] Some comments on Coyotos Microkernel Specification
cap at isg.axmor.com
Thu Dec 8 08:25:32 EST 2005
Jonathan S. Shapiro wrote:
>On Mon, 2005-12-05 at 15:24 -0700, Christopher Nelson wrote:
>>>So in this context, we are merely using SHA-1 (or MD5) as a
>>>deterministic compression scheme.
>>That's what I thought, which is what I was trying to say. I've done the
>>same thing with a less useful hashing algorim (adler32), to speed up a
>>windowing system I developed. It turns out that it wasn't as sparse a
>>function as I had hoped, and the window system only needed deterministic
>>values per run, so an integer-to-string map worked better. For what it
>>seems you are trying to do, hashing seems to me to be a good choice.
>Thanks, and sorry about any confusion. The really good news here is that
>the hash is computed at IDL compile time. This means that we can afford
>to run a good, sparse hash that might be prohibitively expensive at run
I would like to reiterate that I'm considering the intefrace from point
of view of downstream applications. Performance is a major but not the
primary issue for me here. Saving cycles only worth if functionality is
not degraded. However I think that selected hash approach is less useful
to downstream application than plain string approach because less
information is transferred.
I seems now understand why it have been implemented in this way. I still
do not think that this is a good solution. This smells like premature
optimization whithout thorough use case analysis and benchmarks.
Particularly it is not clear which kinds of the applications and how
often have been supposed to call the method and how big overall
performance gain would be if compared with the string in such use cases.
A hash-based solution necessary has more collisions than interface name
by the definition of what a hash function is. So the compression scheme
based on hash is necessary loosy. So please do not use word
"deterministic", because it simply is not. Deterministic compression
scheme should have a deterministic decompression function. And it is not
possible to have the one for a hash function.
Also when type name is not kown in advance (the likely case for shell
and directory services). The overall solution migh have worse
performance because of need execute operations like
service.getTypecode() = hash("coyotos.directory.File") in the shell
languages. If hash is good and expensive as it is suggested, what is
gained on reduced IPC message size will be overcompensated by consequent
So I suggest a simple compromize solution:
- leave getTypeCode() method as it is and document it that is based on
hash and therefore loosy. It still can be useful for a quick typecheck
on input parameters.
- add getTypeName() method that return alleged type name as string.
- add getAllTypeNames() method that return a sequence of strings that
includes type name and and names of all types that are implemetned by
this interface. This method is required to determine if some object on
the directory is a "coyotos.directory.TextPrinter:1.1" even if its type
is something like "com.adobe.PDFPrinter:1.1".
If this is acceptable, then the issue is closed from my point of view.
More information about the coyotos-dev