[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: auth handshake and rendevouz objects
From: |
Neal H. Walfield |
Subject: |
Re: auth handshake and rendevouz objects |
Date: |
05 Nov 2002 18:56:50 -0500 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 |
> 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.
- Re: auth handshake and rendevouz objects, (continued)
- Re: auth handshake and rendevouz objects, Marcus Brinkmann, 2002/11/05
- Re: auth handshake and rendevouz objects, Niels Möller, 2002/11/05
- Re: auth handshake and rendevouz objects, Marcus Brinkmann, 2002/11/05
- Re: auth handshake and rendevouz objects, Tom Hart, 2002/11/05
- Re: auth handshake and rendevouz objects, Marcus Brinkmann, 2002/11/05
- Re: auth handshake and rendevouz objects, Niels Möller, 2002/11/05
- Re: auth handshake and rendevouz objects, Niels Möller, 2002/11/05
- Re: auth handshake and rendevouz objects, Marcus Brinkmann, 2002/11/05
- Re: auth handshake and rendevouz objects, Neal H. Walfield, 2002/11/05
- Re: auth handshake and rendevouz objects, Niels Möller, 2002/11/05
- Re: auth handshake and rendevouz objects,
Neal H. Walfield <=
- Re: auth handshake and rendevouz objects, Niels Möller, 2002/11/06
- Re: auth handshake and rendevouz objects, Michal 'hramrach' Suchanek, 2002/11/11
- Re: auth handshake and rendevouz objects, Marcus Brinkmann, 2002/11/05
- Re: auth handshake and rendevouz objects, Neal H. Walfield, 2002/11/05
- Re: auth handshake and rendevouz objects, Niels Möller, 2002/11/05
- auth handshake and rendevouz objects, Sunnanvind Fenderson, 2002/11/30
- Re: auth handshake and rendevouz objects, Marcus Brinkmann, 2002/11/30
- Re: auth handshake and rendevouz objects, Neal H. Walfield, 2002/11/05
Re: auth handshake and rendevouz objects, Neal H. Walfield, 2002/11/05