[coyotos-dev] Endpoints and replies

[Jonathan S. Shapiro]

[I am forwarding the following note on behalf of Norm Hardy, who
originally sent this to me privately.]

-------- Forwarded Message --------
From: Norman Hardy <norm at cap-lore.com>
To: Jonathan Shapiro <shap at cs.jhu.edu>
Subject: Exposed call count
Date: Tue, 17 Jan 2006 13:04:09 -0800

If there is or was a discussion of this on the coyotos mail list I  
did not see it.
I would be glad to put this on that list (giving you credit) unless  
you object.
You call the "call count" something else—I forget what.
I ran into a problem at the end of the note.

You propose to expose the call count and thus remove hair from the  
kernel.
There are two aspects to this: (1) kernel semantics, (2) kernel  
implementation costs.
The later subdivides into (2a) code size and (2b) code complexity  
(2c) performance.
There is also the issue of new complexity in domain land.

As I understand the proposal the 3 kernel states would be simplified  
by eliding waiting and available.
In their place would be a new state that was receptive to only some  
subset of gate keys and
that subset would be defined by a subset of data byte (GPL (guarded  
pay-load)) values.
Domain logic would somehow specify this subset.
Likewise start keys and resume keys would be elided to mere gate keys.
The call would specify a GPL value for a new key to the caller, much  
as resume keys are
produced in the old plan.
The caller is advised to produce a distinct value upon each call if  
he must guard against stale resumption.

I recall a vague proposal that we did not implement for Keykos, or  
even write down.
It would have given priority on the stall queue to start keys whose  
data byte value was greater than some fixed constant, say 192.
This provided an extremely simple priority scheme that was trivial to  
specify and implement.
If the benefit had been more than hypothetical we would have  
implemented it.
I see no problem in the caller specifying the subset of GPL values  
via which it will accept messages.
It certainly need not be an arbitrary subset.
Indeed it might be all or singlton zot where zot is the GPL value in  
the last call operation.
Allowing some slightly more general subsets might be strategic however.
Perhaps such generality should be deferred until concrete demand is  
observed.

To solve the problem of overflow of GPL values one can use a sever  
operation on the domain (process) root which would dissolve all  
outstanding keys.
That would also dissolve the keys playing the role of start keys in  
the old plan and that is bad.
Alternatively a node could have two sorts of allocation count, as it  
has two in the old plan.
I would call these the front door key and the back door key.
Alas this is tending back to the disadvantages of the old plan.
Have you another idea here?