Efficient UNO component linkage & GC ...

[Stephan Bergmann]

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