...to ease the implementation in C++ code of constructor-based <implementation>s
that shall be single-instance (and which would have been implemented with e.g.
cppu::creaetOneInstanceFactory for non--constructor-based <implementation>s).
See e.g. 6e35794cad "terminate XDesktop properly
in unit tests" and 6362ebab29 "dbaccess: create
instances with uno constructors" for the clumsy approach used until now, where
the C++ constructor function uses a static instance that is cleared in
dispose(), adding fake <singleton> entries to <implementation>s where necessary
so that the ServiceManager will call those XComponent::dispose() functions when
it itself gets disposed.
For every <implementation>, the ServiceManager already holds an Implementation
data structure, so it can easily hold a singleInstance there and clear it when
the ServiceManager gets disposed. (One consequence is that single-instance
implementations are now created with their Instance.mutex locked, but that
should not cause problems in practice, given that the construction of a single-
instance implementation should not recursively request its own construction
anyway.)
The new single-instance="true" attribute is mostly useful in combination with
the constructor attribute (see above), but it can also be used for non--
constructor-based <implementation>s, at least in theory.
(The single-instance="true" attribute is orthogonal to <singleton> elements.
There are existing single-instance services---even if those should arguably have
been defined as singletons in the first place---that can benefit from
single-instance="true". And there are <implementation>s that support one or
more <singleton>s alongside one or more <service>s, where the latter are not
single-instance.)
This new single-instance="true" attribute in *.component files should not
interfere with the lo_get_constructor_map machinery in the DISABLE_DYNLOADING
branch of cppuhelper::detail::loadSharedLibComponentFactory
(cppuhelper/source/shlib.cxx) used by Android, iOS and some fuzzer code.
AFAIU, the lo_get_constructor_map machinery should only ever come into play
after the ServiceManager has decided whether or not to create a new instance
based on the single-instance attributes in the *.component files.
This commit only provides the new single-instance="true" attribute. Actual
changes of <implementation>s and their C++ constructor functions are delegated
to a series of follow-up commits. (So that they can easily be reverted
individually should the need arise.)
Change-Id: Iea6c0fc539d74477b7a536dc771b198df6b0510e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103734
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>