Kay Ramme - Sun Germany - Hamburg wrote:
Arnulf,
life cycle for remote objects is in principal not different compared to
local objects. All UNO objects are reference counted. If the reference
drops to zero, the object destructs itself.
During a remote calls, objects become passed to the other processes. We
only need to differentiate between
-1- objects as results
-2- objects as parameters for synchronous calls
-3- objects as parameters for asynchronous (oneway) calls
-1-: If a method returns an object, the callee must acquire the object
before passing it back. If such a method becomes called asynchronously,
the object must be released by the bridge.
A given URP endpoint should never force a normal (not one-way) UNO
interface method invocation into an asynchronous request message
(urp.html: "doing so violates the specification of the UNO execution
model, and should thus be avoided"). If a given URP endpoint follows
this rule, it does not have to care about releasing objects returned
from asynchronous calls.
-2-: The object passed must already be acquired. The caller needs to
acquire the object only, if it somehow copies a reference.
-3-: The calling bridge must acquire the object before sending the call.
The remote bridge must send a release call, after the asynchronous call
has been executed.
Not sure why you differentiate between synchronous and asynchronous
calls. In either case, urp.html details under which circumstances the
sending side must increment any reference counts, and when the other
side can send back the correspoinding release requests.
If I remember correctly, the current implementations acquire passed
objects before every call and pass release calls for these as in -3-,
mainly for simplicity reasons. This is not as worse as it sounds,
because release calls A) get accumulated and send as a burst, and B) are
asynchronous anyway.
It is not the current implementations, it is the current specification.
The two endpoints of an URP connection have to agree exactly on how
object life cycle is managed.
Remote bridges are reference counted as well and automatically destruct
themselves at the moment the last mapped object gets unmapped, allowing
transparent breakup of remote connections.
Hope that helps
Kay
Arnulf Wiedemann wrote:
Hi,
I am looking for detailed information on what is happening, if I send
a release call to the urp bridge. Especially how do I release local
and remote objects and types (do I just set the appropriate header
flags and put the type and/or object info into the message body, do I
have to release the remote types/objects at all?) and how can I be
sure that the desired release has worked, as the release call is a
one_way call. Any info or link to docu is appreciated.
Arnulf
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
