Do what the TODO suggests - change it to SolarMutex in most cases.
In some cases it is only there to guard a local static, introduce a local
mutex for those.
Change-Id: Idc3155818f737b958b36ee9125e2e9e8cb1b91a1
...and make LockHelper::getGlobalLock() FWI_DLLPUBLIC again (so there's a single
such lock, not one per library).
Change-Id: I0aed77333dc93cdf1c7dd7b96620fb7a8eb3dd64
...and extract it to framework::GlobalLock::get().
The old lock was actually effectively two different locks,
LockHelper::getGloblaLock() and
LockHelper::getGlobalLock().getShareableOslMutex(), and both were used in
different places. These places all use the same single osl::Mutex instance now,
but hopefully that does not lead to problems (which it shouldn't, given the
documentation of LockHelper::getShareableOslMutex: "Sometimes we need a osl-
mutex for sharing with our uno helper ... What can we do? We must use a
different mutex member :-( I HOPE IT WORKS!").
Of course, the "TODO: This presumable should return the SolarMutex" still
applies.
Change-Id: I7caea3241d1b70a00272fe1f2214c071ef22cf2c
Probably it should depend on whether doing tiled rendering or
not. Unclear whether that then can be a compile-time constant, or a
run-time global state, or need to be even more fine-grained.
Change-Id: I8b2f8889e82ecc647ddce915e35eceec121613bd
This is much better approach compared to the callback function, as it allows
passing arguments to the c++ constructor directly, while still allowing some
additional initialization after having acquired the instance.
Change-Id: I5a0f981915dd58f1522ee6054e53a3550b29d624
Many of the initalizations (in eg. framework) have to be done on an
acquire()'d object, so instead of doing the initialization directly, return
the initialization member function back to the createInstance() /
createInstanceWithContext() / ... and perform the initialization there.
As a sideeffect, I belive the calling initialize() from servicemanager is not
that much a hack any more - whoever converts the implementation to be
constructor-base has the choice to provide the callback, or still initialize
through XInitialization, where the callback is preferred by servicemanager
when it exists.
Change-Id: I8a87b75c54c1441ca0f184967d31ff4902fc4081
I thought SAL_WARN_IF etc worked in such a way that any variables used
in the condition would be "used" from the compiler's point of view,
even in an optimising build case where SAL_DETAIL_ENABLE_LOG_WARN is
false and SAL_WARN_IF should optimise away?
Change-Id: I728e1eeb8559e1299abf403afceb0e2748d08857
Also remove declarations for debug function that don't exist (have been
removed (misguidedly?) as unused perhaps).
Change-Id: I0bc3320c52b3d50dc851a07fdc30b593cc4856b1
