[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Correction! Re: Passing object references
From: |
Marcus Brinkmann |
Subject: |
Correction! Re: Passing object references |
Date: |
Sun, 15 Dec 2002 04:24:28 +0100 |
User-agent: |
Mutt/1.4i |
Hi,
I goofed up. I edited it, but the edit was not complete. All occurences of
the wait flag W have to be removed. The following is the corrected version:
1. Task A sends a message to S to initiate the reference passing operation.
Task A tells S which reference (O_A) it wants to move to which task (B).
The server will return a transaction number T_A, which is unique to a
task, and makes a transaction record (O, A, T_A, B, W) in the server.
Note: The transaction number has the same job as the rendezvous port in
auth.[1]
2a. Now task A sends the message to B it wants to send. This can be a simple
message (without reply), or a normal message with a blocking receive.
In the message, all send rights are represented by (S, T_A)[2].
2b. If A wants to synchronize with handle reception, it can
sent a message to S which blocks until the handle was received by B
(the transaction record will tell). (Optionally: once that happens,
the transaction record will be removed before replying success to A.
Note: This will only happen if the message in 2a was not a normal reply
message. In a normal reply message, success from B means that all handles
that B was interested in have been successfully received, so no
explicit synchronization is necessary. This is the common case!
2c. Task A sends a message to S to destroy the transaction record T_A.
Note: Optionally, this can be automatic if there is a successful
synchronization (and only on synchronization failure or without
explicit synchronization this step is necessary).
Note: This is analogeous to the deallocation of the rendezvous port.
Note: This step is important! If you don't do that, either unused
transaction records can pile up (if B is simply not interested in receiving
them) or transaction numbers can be reused too early and confuse A
(although this is very unlikely if you choose a 32 bit number carefully).
3. Task B receives a message from B. For each handle it wants to receive,
it sends a message to S with (S, A, T_A). The server S will then look
up the transaction record, and create the object handle O_B for B, which
it will return. Before returning it will set a flag internally that
means that the handle was received. If there are pending synchronization
requests, they are woken up (they will see the internal flag, and then
see 2b)
--
`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/