l4-hurd
[Top][All Lists]
Advanced

[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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]