Re: auth handshake and rendevouz objects

[Neal H. Walfield]

> And I'm afraid I'm not quite sure what counts as a timeout. If there S
> sends a message to A, with zero timeout, and A is ready to receive but
> isn't scheduled for a while, will the call timeout?

No.  If A is in the receive state, the register transfer is done
immediately--if I remember the details correctly.

> If A is ready to
> receive, and a dozen threads sends rpc:s to it at about the same time,
> all with zero timeout, can one be sure that all but one of the rpc:s
> will timeout?

How can a dozen threads send rpcs at the same time?!?  We simulate
concurrency and even in SMP machines, there will be locks.

> > in clients.  I have pondered this in the past, and did not come to a
> > conclusion yet.  In Mach, we have the concept of buffering and the
> > possibility to receive a notification when the receiver is ready.
> 
> Would it help to have a single one-message buffer per-receiver (in our
> case, A), in S, and a corresponding thread? When B asks for one of A:s
> handles, it will block until the server's buffer is empty. Then the
> server thread will receive the message from B, and it can block while
> delivering it to A (using the same timeout as B used when calling
> S).

The point is that the server is not suppose to block.  Doesn't this
algorithm defeat that?

> * A number of threads that is linear in some potentially pretty large
>   parameter, like number of open files, number of clients, etc. I
>   don't know if this is a problem, it seems to be a basic assumption
>   in the hurd design that threads are cheap.

That is not what is currently done.  There is one thread per
outstanding rpc.  Or are you suggesting something else?

> * Unpredictable behaviour if a malicious task floods other threads
>   with messages. I'm afraid that is a problem that's hard to solve,
>   and which we should perhaps ignore for now. I think it's basically a
>   resource limits and resource allocation problem. Sending a message
>   should cost you some cpu-time in the scheduling algorithm, to
>   compensate for the cputime it costs the receiver to check if you're
>   authorized to talk to it.

This would be horrible and I cannot think of anyway around it.  The
handle thread must do an open wait and as such the possibility exists
that its thread id will be guessed by a rogue process.