Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


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.





Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.