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


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.