Re: synchronous RPCs vs. asynchronous RPCs

[Marcus Brinkmann]

On Fri, Sep 05, 2003 at 01:44:52AM +0200, Marcus Brinkmann wrote:
> "We should only do synchronous RPCs, and implement all asynchronous RPCs as
>  synchronous RPCs performed by a helper thread."

I have thought a bit more about this, and it seems to be the right paradigm
to me.  Here is why:

A server in an untrusted multi-server OS should not really provide much
services to its clients.  Rather, it should restrict itself to access
control, which also allows resource sharing.  For example a filesystem
is all about sharing and restricting access to a storage device.
Of course, this is not a strict rule.  Certainly, some Hurd servers do in
fact provide further services beyond that.  More often than not this is also
to allow to implement the POSIX standard semantics.

Now, we have solved the memory consumption problem with Neal's container
model.  We have not solved (and do not intend to solve) the CPU time
consumption problem.  A server will run a user RPC on its own CPU time.  (I
think other OSs like EROS use capabilities even for CPU time, and might have
a solution for this problem).  What I thought is that in an ideal world
(ideal world means we can ignore all potential problems ;), the client
thread would not send a message to a server thread to do RPC.

Instead, the client thread would migrate to the server's address space, and
run there.  After completing the operation, the client thread would migrate
back.  This way, the time that the client spent in the server would be
attributed to the client thread.  It is obvious that this opens a pandora's
box of problems, from priority inversion to robustness issues (what if the
client thread runs out of its cpu time quota while holding a server side
lock? for example).

However, this is why I said "ideal world".  Nevertheless I think that it
might (repeat: might!) be a good idea to design the Hurd interfaces wherever
it is possible in a way to allow such a thread migration scheme.  And the
synchronous RPC model, where one client thread is only allowed one RPC on
the server side, seems to come as close to the thread migration model as we
can.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/