Stephan,
Stephan Bergmann wrote:
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.
via the extended bits for MUSTREPLY respectively SYNCHRONOUS one can
override a methods oneway/!oneway specification. This makes sense and is
valid and for example gets used when providing FORCE_SYNCHRONOUS.
Originally this was already in preparation for CuCas (Customized CAlls),
which have not been implemented yet.
-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.
I differentiated for completeness, to understand the different scenarios.
The reason for acquiring objects passed in synchronous calls is the
"acquire" method being oneway, avoiding potential races between a client
acquiring (sending an acquire request) an object passed to a synchronous
call and returning from this synchronous call.
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.
You are right.
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
