So-called purpose UNO environments (i.e., the "affine" and "unsafe" ones
implemented in cppu/Library_affine_uno_uno.mk and
cppu/Library_unsafe_uno_uno.mk, resp.) are designed to introduce a UNO
bridge (acting according to a specific "purpose") between different
regions of C++ code: Code inside the region (running inside the purpose
environment) communicates with code outside the region (running in the
normal C++ UNO environment) only through UNO interface calls, and those
calls all go through bridged proxy objects (instead of being direct
native C++ to C++ virtual function calls).
The ado and jdbc drivers in module connectivity use the affine
environment to restrict those drivers' code to only execute on one
specific thread (as is presumably required by the underlying ado resp.
jdbc code that they call into).
Now, code outside the purpose environment can pass a reference to a UNO
object into the purpose environment (and vice versa) in two ways, one
good and one bad:
* Good: Among the arguments or return value of a UNO interface call.
The bridge will wrap that reference in a proxy, all fine.
* Bad: Via direct access to global state. The most prominent example
is calling comphelper::getProcessComponentContext inside a purpose
environemnt, which will provide unbridged access to the
XComponentContext running outside the purpose environment. So when
making calls on that XComponentContext from within the purpose
environment, the called code will suddenly start to wrongly run inside
the purpose environment! (This shows why
comphelper::getProcessComponentContext is a convenient but dumb idea.)
Another example is the recent
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=03a271901c39d60e4519e67e258d565ad5e1e085>
"Guard against globally shared UNO ref accessed from wrong UNO env."
PS: For comphelper::getProcessComponentContext, a patch like
diff --git a/comphelper/source/processfactory/processfactory.cxx
b/comphelper/source/processfactory/processfactory.cxx
index 211067a..d7ca3af 100644
--- a/comphelper/source/processfactory/processfactory.cxx
+++ b/comphelper/source/processfactory/processfactory.cxx
@@ -18,6 +18,7 @@
*/
#include <osl/mutex.hxx>
+#include <uno/environment.hxx>
#include <comphelper/processfactory.hxx>
#include <com/sun/star/lang/XMultiServiceFactory.hpp>
@@ -52,11 +53,17 @@ Reference< XMultiServiceFactory > localProcessFactory( const
Reference< XMultiSe
void setProcessServiceFactory(const Reference< XMultiServiceFactory >& xSMgr)
{
+css::uno::Environment env(css::uno::Environment::getCurrent());
+assert(env.is());
+assert(env.getTypeName() == CPPU_CURRENT_LANGUAGE_BINDING_NAME);
localProcessFactory( xSMgr, true );
}
Reference< XMultiServiceFactory > getProcessServiceFactory()
{
+css::uno::Environment env(css::uno::Environment::getCurrent());
+assert(env.is());
+assert(env.getTypeName() == CPPU_CURRENT_LANGUAGE_BINDING_NAME);
Reference< XMultiServiceFactory> xReturn;
xReturn = localProcessFactory( xReturn, false );
if ( !xReturn.is() )
could catch cases where it erroneously gets called from within a purpose
environment. Then again, purpose environments are rare enough in
practice, and I only found a single problematic
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=9610a5aebd3ffdf76bcb734c633b5f88b78ad4dd>
"Use passed-in context instead of
comphelper::getProcessComponentContext()" when running "make check" with
that patch enabled. So it might not be worth it to commit that.
_______________________________________________
LibreOffice mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
