Hi,
I have been busy lately adding support for UNO's current context concept
(see
<http://udk.openoffice.org/common/man/concept/uno_contexts.html#current_context>)
to URP (on CWS sb23, not targeted for OOo 2.0, but probably OOo 2.0.1).
fine :-).
That this feature is currently missing has been noticed by the
initiative to make OOo multi-thread safe when accessed via UNO.
This was a known limitation, wasn't it ?
Now, to make a thread's current context available via URP: The only
working scheme that I came up with is also the most primitive one---send
the current context along with every URP request (i.e., every invocation
of a UNO interface method;
Agreed, at least heavily thinking this through some years ago lead me to
the same single solution.
the current context is not sent along with
URP "release" requests).
This is needed (otherwise one would have an endless loop as every uno
call now needs also a release call for the current context).
C++, one Java) from the testtools module on my local Linux box: (a) on a
plain SRC680m88 (i.e., without support for current context); (b) on CWS
sb23 (i.e., with support for current context), but using a null current
context in the active thread; and (c) on CWS sb23 (i.e., with support
for current context), and using a non-null current context instance in
the active thread. (Also, I changed the bridgetest_xxx scripts to use
TCP connections with tcpnodelay=1, see the Developer's Guide for details.)
What does happen, when you don't give this option ? In case, a current
context is transported you probably get disastrous results (the
additional release calls for the current context trigger this problem,
bit I don't remember the exact circumstances anymore). As most people
don't use tcpdelay right now, introducing this feature will create some
noise, I think (depending on how much currenct contexts are use
currently). One just needs to keep this in mind. It's a little sad, that
the standard connection string needs to be extended by this option, but
I don't see another solution here.
Timings for three sample runs each are below, and indicate that the
changes are tolerable (esp. if you consider that those brdigetest tests
have an URP call density that is quite high, higher probably than that
of the typical application). However, if you have any concerns about
these changes, feel free to discuss them here.
No more other concerns, except that it needs to be said, that this
change will be incompatible (meaning that a 2.0.0 Office won't be able
to talk to 2.0.1 office), won't it ?
Bye,
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
