Kernel RPC/Resume Keys

[Bryan Ford]

>   By the way, I always felt that "send-once" rights were the wrong
>   abstraction. In KeyKOS, and I suspect Mach, most messages are in the
>   form of a request by a thread which then waits for the reply...
>
>One could imagine an alternative design in which a process was allowed
>to have multiple outstanding calls, effectively doing asynchronous RPC
>with several services at once.  A particularly useful case of this
>would be asynchronously sending a message for which you expect a
>reply, and then calling a key that replies when the time is up
>(call/return with timeout).

Presumably there is already some standard way to implement
call-with-timeout and similar in KeyKOS; the obvious method that
occurs to me is to create an intermediate process to make the call
and terminate the process if the call times out.  Is there an
easier way?  For example, is it possible in KeyKOS to force a
domain out of the waiting state and invalidate its resume keys,
without destroying the domain?

>Bryan: How is this problem (client not listening when server needs to
>reply) addressed in the migrating threads system, where there isn't a
>message queue?

Just like in KeyKOS: while the client is doing a migrating RPC,
it's not doing _anything_ else.  The model allows a third-party
thread to use the client's control port to abort the RPC,
in which case the return link is permanently severed and when/if the
server does eventually return its reply message drops into the void.
I never actually implemented this abort mechanism, although it
doesn't seem like it should introduce any particular problems.

				Bryan