Kernel RPC/Resume Keys

[Jonathan Shapiro]

   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).

In this handwaving design, a resume key contains a *caller supplied*
32-bit sequence number, and the sequence number validation is done in
user code.  On return, the serial number is lifted from the resume key
and handed to the process, so servers cannot forge them.  In a typical
client you'll end up doing the same thing that the kernel currently
does, but by doing sequence validation in the client you can have
multiple RPC's outstanding.  The primative methods would then be Send,
Wait, and SendAndWait.  The send portions have an option telling the
kernel to generate a resume key or not.

Resume key send once is not kernel enforced, which eliminates the need
for a call count in the Node (which I never liked in any case).


Oh.  Stupid of me.  The problem with this design is that a server
cannot rely on the fact that a return operation will be prompt,
because the client may be running in response to a different resume.
A pernicious client can therefore block the server.  Adding buffering
to the message subsystem just makes things worse.

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?

Jonathan