On 01/23/2014 10:29 AM, Matúš Kukan wrote:
On Fri, 2014-01-17 at 10:18 +0100, Stephan Bergmann wrote:
On 01/16/2014 06:52 PM, Stephan Bergmann wrote:
Ah, so it seems that Singleton::get(context).instance does not work
always. In framework, there are many one instance services, and when I
tried to use static Singleton class in ctor function for e.g.
framework::Desktop, I get various crashes on atexit.
Yes, as stated on IRC, "in the old scheme, disposing the service mgr it
would have disposed the implementation's singleinstancefactory object,
which would have destroyed the singleton object; we need to mimic that
via the singleton object now implementing XComoponent (which the service
mgr will call when it gets disposed) wherever necessary."
...as they are not only called from the service manager (which takes care of
singleton constructor functions since 997d21183322a0a94b96868073808841d2773902
"Support for singleton constructor functions") but potentially also directly
from cppumaker-generated code (which is the raison d'être for constructor
functions, after all).
AFAICS singletons in generated code don't use constructor functions yet.
Right, that's still missing. Do you want to add that (otherwise, I
could see to do it sometime next week)?
And maybe it's a good thing.
We could use always context->getValueByName("/singletons/<name>"); and
it would work ?
After changing
css::uno::XInterface *inst = Singleton::get(context).instance.get();
inst->acquire();
return inst;
back to
return cppu::acquire(new SfxGlobalEvents_Impl(context));
But that would completely deprive us of the benefits of using
constructor functions for singletons in the first place.
* makes it questionable whether the service manager holding references of these
singletons (introduced in 997d21183322a0a94b96868073808841d2773902) is
necessary after all; lets revisit that in another commit.
I would keep it, and use only that, unless you know how to fix it
another way?
See above; keeping this and changing singleton ctor functions to always
return fresh instances would be rather pointless.
I wish, there would be something simpler possible, because adding
singleton deprecating the service for 13 services is not fun.
But it is a good change in and of itself to replace odd "singleton
services" with true singletons.
Maybe something like you wrote
** or use some <implementation single-instance="true" flag
in .component
XML and implement the logic of holding a single instance in the
service
manager, which would dispose them when it gets disposed well ahead of
exit
Writing that I didn't take into account the direct-call case; consider
it moot.
Stephan
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.