Efficient UNO component linkage & GC ...

[Matúš Kukan]

On Fri, 2014-01-17 at 10:18 +0100, Stephan Bergmann wrote:
> On 01/16/2014 06:52 PM, Stephan Bergmann wrote:
> > So the way out is to distinguish singleton implementations (whose XML
> > description lists at least one <singleton ...>) from normal ones (whose
> > XML description does not list any <singleton ...>s), and let the service
> > manager keep track to only create a single instance of those.
> >
> > And for those "false singletons" that are normal implementations by the
> > preceding definition but use a single-instance factory, turn them into
> > singleton implementations (typically by deprecating an existing UNOIDL
> > service and introducing a superseding UNOIDL singleton), and, voila, you
> > can convert them to use constructor functions without further ado.
> >
> > <http://cgit.freedesktop.org/libreoffice/core/commit/?id=997d21183322a0a94b96868073808841d2773902>
> > "Support for singleton constructor functions" implements the necessary
> > machinery in the service manager, and
> > <http://cgit.freedesktop.org/libreoffice/core/commit/?id=997d21183322a0a94b96868073808841d2773902>
> > "Introduce com.sun.star.frame.theGlobalEventBroadcaster singleton" and
> > <http://cgit.freedesktop.org/libreoffice/core/commit/?id=3557c07899e363a9b7e1cceca632ad9112d039a2>
> > "Revert 'Revert 'sfx: Use constructor feature for
> > SfxGlobalEvents_Impl''" demonstrate how to apply it to
> > SfxGlobaleEvent_Impl.
> 
> Bummer.  Where was my brains?  This of course also requires 
> <http://cgit.freedesktop.org/libreoffice/core/commit/?id=d7a397ca101999a2910c9087d708e0a8c0ea4c2e> 
> "Constructor functions for singletons still need to pass out single 
> instances":

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.

> > ...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.
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));

> > However, this change:
> > * postpones the instance's destruction to atexit, with all dreaded consequences;
> >   lets see how that pans out.
yep, unfortunately it creates problems :-(

> > * 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?

I wish, there would be something simpler possible, because adding
singleton deprecating the service for 13 services is not fun.
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

but I guess this has the same effect as creating a singleton which is
better thing to do ?

Hope this email makes sense,

Matus