Re: Efficient UNO component linkage & GC ...

[Michael Meeks]

Hi Stephan,

Thanks for the review ! Matus should start work on this shortly.

On Fri, 2013-10-11 at 17:20 +0200, Stephan Bergmann wrote:
> DllComponentLoader is mostly dead by now, only comes into play during 
...
> Handling of the prefix feature is done entirely in 
> cppuhelper/source/servicemanger.cxx and cppu::loadSharedLibComponentFactory.

Ah right my bad; as you say we should add this here: 

> To split into smaller,  unconnected parts would mean to split existing
>  XML entities into smaller ones, each with its own prefix 

That would suck IMHO :-) we have enough scattered files.

> Or, as you detail below, go further and add more efficient support for 
> the "single-object-implementation" factory case.  (Do you have any idea 
> whether this is worth it, given we have to continue supporting the other 
> case for extension-compatibility anyway?)

Sure it's worth it given we're primarily looking for size savings for
mobile; for the Linux case we get only marginal wins here I think.

> Anyway, given that the current "prefix" feature should only be used by 
> internal code we have under full control (see recent discussion 
> elsewhere on this mailing list), should we go down that road, I'd prefer 
> to replace the existing "prefix" feature with something new (e.g., an 
> extension of the components XML schema that associates an individual 
>  rather than a  with a prefix attribute), 
> rather than keeping both.  (Though we could support both for a 
> transition period while we incrementally update the existing code.)

Yep - agreed; it's nice we're flexible here, just some inevitable
transition period where we'd try the direct symbol approach, and then
fallback to the old prefix'd factory function.

> What would likely be more entertaining is to get rid of the 
> cppu::createSingleFactory layer of indirection.  (As you come to in part 
> three.  But note that there are service implementations that rather act 
> like singletons and always hand out the same object instance; that needs 
> to be taken care of.)

Yes - hopefully that's easily done. Luckily it's all internal, was just
chatting with Matus and considering the symbol could point to a C struct
easily enough something like:

extern "C" struct {
const char*pImplementationName;
ComponentInstantiation pCreateFunction
const char*pServiceNames[];
} ComponentEntryPoint;

And have some wrappers to help with converting the ComponentEntryPoint
record into the results we want from the XServiceInfo methods
(getSupportedServiceNames etc.)

> An alternative is to extend the components XML schema to support lookup 
> of the factory function directly in the executable (say) rather than a 
> given dynamic library (e.g., by having a local="true" attribute rather 
> than a uri="..." one).  Since the uri attributes are already inserted 
> into the .component XML files at build-time, it shouldn't be too hard to 
> combine that with a configurable list of components that end up directly 
> linked into the executable.

Interesting idea. I'd like to see how this shakes out in a few
iterations here I think. I agree that we're going to need something
like:

 http://openoffice.org/2010/uno-components";>
- 
+ 

  
  


  

Incidentally - do we actually use the service information in anger ?
ie. could we not populate / store the data required for the XServiceInfo
interface from the services.rdb at run-time, rather than having it
duplicated in the code ? or is there some benefit to that ?

> In addition to having them stored as XML files that are parsed at start-up in 
> cppuhelper::ServiceManager::init, one could optionally have them 
> pre-compiled into some data structure that is accessible from 
> cppuhelper/source/servicemanager.cxx.  In which case the data structures 
> for such local="true" components could directly contain function 
> pointers to the corresponding factories.

Very true =) perhaps that would get rid of the whole native-code.cxx
mess as well - centralizing it and making it fully generic - that would
be nice.

> > * Part three - faster component instantiation
> >
> > The wonderful work Noel has been doing around more beautiful
> > ways to instantiate components should dove-tail with this nicely.
...
> > Which should be much smaller and neater.
> 
> Question is how much that "much" would actually be.  (And one would have 
> to generate two variants of service/singleton C++ headers, an optimized 
> one for internal use and a traditional one for external use.)

Well if we call directly into the method that instantiates the object,
then LTO can potentially start to inline a lot of things and ignore a
lot of exceptions that we know are not thrown etc. presumably it may
have some benefits for a merged-libs case.

Anyhow - thanks for the feedback - moving ahead here soon (I hope) on
master.

   

Re: Efficient UNO component linkage & GC ...

[Stephan Bergmann]

On 12/12/2013 02:47 PM, Michael Meeks wrote:

To split into smaller,  unconnected parts would mean to split existing
 XML entities into smaller ones, each with its own prefix


That would suck IMHO :-) we have enough scattered files.


To be clear, this is about source files, not installation-/run-time ones.


Or, as you detail below, go further and add more efficient support for
the "single-object-implementation" factory case.  (Do you have any idea
whether this is worth it, given we have to continue supporting the other
case for extension-compatibility anyway?)


Sure it's worth it given we're primarily looking for size savings for
mobile; for the Linux case we get only marginal wins here I think.


I'd assume the major size savings would come from leaving out unused 
areas of code, and that would already be possible without the "go 
further" part.



Incidentally - do we actually use the service information in anger ?
ie. could we not populate / store the data required for the XServiceInfo
interface from the services.rdb at run-time, rather than having it
duplicated in the code ? or is there some benefit to that ?


The duplication is an unfortunate consequence of the move from active to 
passive component registration.  And as the code was already there, I 
never bothered too much to change that to instead re-use the .rdb data. 
 (Which wouldn't have been easy or elegant, but that might be different 
if we represent the .rdb data not in an additional file read at start-up 
but in some compiled-in data structures).


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Michael Meeks]

On Fri, 2013-12-13 at 11:36 +0100, Stephan Bergmann wrote:
> To be clear, this is about source files, not installation-/run-time ones.

Sure - but even so - there are a lot of components ;-)

xmllint --format services.rdb | grep ' >> Or, as you detail below, go further and add more efficient support for
> >> the "single-object-implementation" factory case.  (Do you have any idea
> >> whether this is worth it, given we have to continue supporting the other
> >> case for extension-compatibility anyway?)
> >
> > Sure it's worth it given we're primarily looking for size savings for
> > mobile; for the Linux case we get only marginal wins here I think.
> 
> I'd assume the major size savings would come from leaving out unused 
> areas of code, and that would already be possible without the "go 
> further" part.

True - but while we're here - AFAICS we should go further to clean that
up & make it more efficient =) it's a golden opportunity I think.

> The duplication is an unfortunate consequence of the move from active to 
> passive component registration.  And as the code was already there, I 
> never bothered too much to change that to instead re-use the .rdb data. 
>   (Which wouldn't have been easy or elegant, but that might be different 
> if we represent the .rdb data not in an additional file read at start-up 
> but in some compiled-in data structures).

Yes - it's a great idea. I love it as an iteration - not least because
it should/could kill all that horrible native-code.cxx duplication =)
Then again it's quite nice to be able to build multiple binaries with
different component sets included from the tree - so I guess having some
form of run-time registration of some nice const static component
descriptions would be cool.

Anyhow - looking forward to what Matus comes up with =)

Regards,

Michael.

-- 
 michael.me...@collabora.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Stephan Bergmann]

On 12/13/2013 12:02 PM, Michael Meeks wrote:

On Fri, 2013-12-13 at 11:36 +0100, Stephan Bergmann wrote:

To be clear, this is about source files, not installation-/run-time ones.


Sure - but even so - there are a lot of components ;-)

xmllint --format services.rdb | grep '

Sure.  And I'm not saying at all we shouldn't move ahead, just wanted to 
clarify build vs. runtime here.



I guess until we have mergedlibs on Windows, we can't easily dispense
with the .component files for internal components and just build an
internal data-structure. Even if we did, I imagine compiling /
generating that from .component files might be more interesting &
elegant anyway.


Probably depends on how most elegantly to share the per-service-impl 
info needed by both the service mgr and the impl's XServiceInfo.



True - but while we're here - AFAICS we should go further to clean that
up & make it more efficient =) it's a golden opportunity I think.


Btw, we have rather good conditions there wrt not having to care about 
compatibility too much:


Extension components are restricted to legacy active registration 
(covered by DllComponentLoader calling 
cppu::loadSharedLibComponentFactory w/o prefix) and to the original 
components XML schema (sans prefix attribute) for passive registration. 
 That's all we need to keep stable.


Nowadays, the only code involved for passively registered components are 
cppuhelper/source/servicemanager.cxx reading the .rdb data and passing 
off instantiation requests to cppuhelper/source/shlib.cxx.  For 
historical reasons they do so via a published additional 
cppu::loadSharedLibComponentFactory overload (with additional prefix 
argument), but that communication channel should rather be private.


That is, we can easily extend the components XML schema, even removing 
features again in a later LO version.


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Stephan Bergmann]

On 12/13/2013 12:56 PM, Stephan Bergmann wrote:

Nowadays, the only code involved for passively registered components are
cppuhelper/source/servicemanager.cxx reading the .rdb data and passing
off instantiation requests to cppuhelper/source/shlib.cxx.  For
historical reasons they do so via a published additional
cppu::loadSharedLibComponentFactory overload (with additional prefix
argument), but that communication channel should rather be private.


Made it private now with 
 
"[API CHANGE] remove cppu::loadSharedLibComponentFactory w/ rPrefix 
again" (which is only nominally an API change).


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Stephan Bergmann]

thought-dump:

* loader != "com.sun.star.loader.SharedLibrary" (i.e., Java, Python, 
...) remains unchanged


* external code (extensions) remains unchanged (i.e., stuck with the 
original .component XML format for now; no prefix="...", 
extension="...", constructor="..."; mandatory 
component_getImplementationEnvironment); this allows to experiment with 
the new features internally


* assume all LO-internal C++ implementations are ComponentContext-based 
(i.e., use cppu::createSingleComponentFactory or 
cppu::createOneInstanceComponentFactory rather than legacy 
ServiceManager-based cppu::createSingleFactory or 
cppu::createOneInstanceFactory); reaching this state is effectively an 
easy hack


* implementations of non-single-instance services can be rewritten using 
the new .component XML  
"Add .component effectively an easy hack (note that service manager's 
createInstanceWithArguments[andContext] no longer uses the 
css.lang.XInitialization protocol on those implementations)


* for implementations of single-instance services/singletons, we can:

** either stick with the recently introduced prefix="direct" feature, 
where the service manager obtains a factory for them; any instantiated 
object instances will continue to be disposed well ahead of exit via 
disposing the ComponentContext in desktop::Desktop::DeInit 
(desktop/source/app/app.cxx)


** or also use the constructor="..." feature, in which case the 
individual constructor functions would need to hold a single instance, 
which could postpone that instance's destruction to atexit, with all 
dreaded consequences (an option might be to hold the single instance weakly)


** or use some 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


* next step is to let certain occurrences of UNO service constructor 
(and singleton getter) calls in C++ code call corresponding constructor 
functions directly (instead of going via service manager's 
createInstanceWith[ArgumentsAnd]Context); conditions under which this 
simplification can be done:


** caller and implementation use the same environment (e.g., both gcc3; 
this is not the case e.g. for 
connectivity/source/drivers/jdbc/jdbc.component's 
environment="@CPPU_ENV@:affine")


** and caller knows that the constructor function is visible (i.e., the 
library/executable supplying it is loaded)


** note that there are always situations where UNO services are not 
called via constructor, though; e.g., the constructor-less 
css.uri.UriSchemeParser_* services are always created via dynamically 
computed name


* idea is to set aside for every UNO service/singleton S two macros 
LO_URE_CTOR_ENV_ and LO_URE_CTOR_FUN_, and a macro 
LO_URE_CURRENT_ENV, and modify cppumaker to generate constructor code as



#if defined LO_URE_CURRENT_ENV && defined LO_URE_CTOR_ENV_ \
&& defined LO_URE_CTOR_FUN && LO_URE_CURRENT_ENV == LO_URE_CTOR_ENV_

extern "C" cppu::ConstructorFunction_type LO_URE_CTOR_FUN;

static css::uno::Reference S::create(
css::uno::Reference const & the_context)
{
return LO_URE_CTOR_FUN(
the_context, css::uno::Sequence());
}

#else

// ... existing code ...

#endif


and

** when compiling .cxx files for which the env in which they will be run 
is statically known (which could e.g. be the case for /every/ .cxx file 
for Android/iOS when we restrict ourselves to just that env there, as we 
already effectively do), pass -DLO_URE_CURRENT_ENV=...


** when compiling .cxx files for which it is known that the constructor 
function for some S will be visible (which could e.g. be ~always the 
case when compiling for a single big executable on Android/iOS), define 
the LO_URE_CTOR_ENV_ and LO_URE_CTOR_FUN_ macros, either via -D 
or via some strategically included header


where S' is some schema to convert UNOIDL service/singleton names into 
legal yet unambiguous parts of C++ identifiers, and the encoding of 
environments (which are normally strings) in LO_URE_CURRENT_ENV and 
LO_URE_CTOR_ENV_ macros must be such that they can be used in the 
preprocessor == expression above


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Tor Lillqvist]

> any instantiated object
> instances will continue to be disposed well ahead of exit via disposing the
> ComponentContext in desktop::Desktop::DeInit

BTW, please note that for the platforms where we do
DISABLE_DYNLOADING, a process that uses LibreOffice code (i.e. an iOS
or Android app) will never exit gracefully and intentionally, but
always be killed by the OS at a point in time when it is not active
and the OS needs its resources for other purposes. So for the
DISABLE_DYNLOADING case, tweaks to stuff that happens when LO exits
gracefully is fairly pointless. (Could still be useful for other
platforms, of course.) (Dunno if there is any possibility that
somebody would ever want to use DISABLE_DYNLOADING on more traditional
platforms.)

I wouldn't be surprised if this is the direction where "apps" in
desktop environments will be expected to evolve, too: No more "exit"
or "quit" functionality that the user would invoke. But we are not
there yet.

> * next step is to let certain occurrences of UNO service constructor (and
> singleton getter) calls in C++ code call corresponding constructor functions
> directly

This sounds lovely!

--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Stephan Bergmann]

On 12/19/2013 11:22 AM, Tor Lillqvist wrote:

any instantiated object
instances will continue to be disposed well ahead of exit via disposing the
ComponentContext in desktop::Desktop::DeInit


BTW, please note that for the platforms where we do
DISABLE_DYNLOADING, a process that uses LibreOffice code (i.e. an iOS
or Android app) will never exit gracefully and intentionally, but
always be killed by the OS at a point in time when it is not active
and the OS needs its resources for other purposes. So for the
DISABLE_DYNLOADING case, tweaks to stuff that happens when LO exits
gracefully is fairly pointless. (Could still be useful for other
platforms, of course.) (Dunno if there is any possibility that
somebody would ever want to use DISABLE_DYNLOADING on more traditional
platforms.)


noted; but this simplification of single-instance service/singleton 
construction will be relevant for the "traditional" platforms, too


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Stephan Bergmann]

On 12/19/2013 10:51 AM, Stephan Bergmann wrote:

* next step is to let certain occurrences of UNO service constructor
(and singleton getter) calls in C++ code call corresponding constructor
functions directly (instead of going via service manager's
createInstanceWith[ArgumentsAnd]Context); conditions under which this
simplification can be done:

** caller and implementation use the same environment (e.g., both gcc3;
this is not the case e.g. for
connectivity/source/drivers/jdbc/jdbc.component's
environment="@CPPU_ENV@:affine")

** and caller knows that the constructor function is visible (i.e., the
library/executable supplying it is loaded)

** note that there are always situations where UNO services are not
called via constructor, though; e.g., the constructor-less
css.uri.UriSchemeParser_* services are always created via dynamically
computed name

* idea is to set aside for every UNO service/singleton S two macros
LO_URE_CTOR_ENV_ and LO_URE_CTOR_FUN_, and a macro
LO_URE_CURRENT_ENV, and modify cppumaker to generate constructor code as

[...]

i.e., 
 
"WIP: Direct service ctor calls at least on Android/iOS"


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Matúš Kukan]

Hi Stephan,

some great work, thanks.

On Thu, 2013-12-19 at 10:51 +0100, Stephan Bergmann wrote:
> thought-dump:

really helps :-)

> * assume all LO-internal C++ implementations are ComponentContext-based 
> (i.e., use cppu::createSingleComponentFactory or 
> cppu::createOneInstanceComponentFactory rather than legacy 
> ServiceManager-based cppu::createSingleFactory or 
> cppu::createOneInstanceFactory); reaching this state is effectively an 
> easy hack

Yep, but maybe we don't need special easy hack for this.
So far, I was able to just remove the variables as unused.
I think it's easy to do as part of creating constructor function for
implementation.

> * implementations of non-single-instance services can be rewritten using 
> the new .component XML  
>  
> "Add .component  effectively an easy hack (note that service manager's 
> createInstanceWithArguments[andContext] no longer uses the 
> css.lang.XInitialization protocol on those implementations)

Hm, what does it mean, it no longer uses css.lang.XInitialization
protocol?
What to do about implementations inheriting from XInitialization?
I tried to convert such class in
https://gerrit.libreoffice.org/#/c/7186/
Does it look good ?
If it's clear when to assert for arguments->nElements and what to do
about initialize() we should create an easy hack for this I think.

> * for implementations of single-instance services/singletons, we can:

Sorry, no opinion on this from me. ;-)

> ** note that there are always situations where UNO services are not 
> called via constructor, though; e.g., the constructor-less 
> css.uri.UriSchemeParser_* services are always created via dynamically 
> computed name

Ah, good to know we need to care about such cases.

> * idea is to set aside for every UNO service/singleton S two macros 
> LO_URE_CTOR_ENV_ and LO_URE_CTOR_FUN_, and a macro 
> LO_URE_CURRENT_ENV, and modify cppumaker to generate constructor code as
> 
> > #if defined LO_URE_CURRENT_ENV && defined LO_URE_CTOR_ENV_ \
> > && defined LO_URE_CTOR_FUN && LO_URE_CURRENT_ENV == 
> > LO_URE_CTOR_ENV_
> >
> > extern "C" cppu::ConstructorFunction_type LO_URE_CTOR_FUN;

Is not LO_URE_CTOR_ENV_ redundant ?
We can just check for defined LO_URE_CTOR_FUN ?

> ** when compiling .cxx files for which it is known that the constructor 
> function for some S will be visible (which could e.g. be ~always the 
> case when compiling for a single big executable on Android/iOS), define 
> the LO_URE_CTOR_ENV_ and LO_URE_CTOR_FUN_ macros, either via -D 
> or via some strategically included header

Yes, so this needs some thought.
If I see correctly, there are already some typos in
15abebbde560e17413f17b16b8b2e9c1f31f01a5
like LO_URE_CTOR_FUN_com_dot_sun_dot_star_dot_xml_dot_sax_dot_FastParser
vs.
LO_URE_CTOR_FUN_com_dot_sun_dot_star_dot_comp_dot_extensions_dot_xml_dot_sax_dot_FastParser

Unfortunately I can't see how to avoid these macros, so I'll try to
generate include/osl/detail/component-defines.h early in build process.
Do you have another idea ?

Overall, this looks really good,
Thanks,

Matus

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Michael Meeks]

Hi Stephan,

On Mon, 2013-12-23 at 18:44 +0100, Matúš Kukan wrote:
> > * implementations of non-single-instance services can be rewritten using 
> > the new .component XML  > 
> >  

I'm concerned that we already have way too many, far too verbose XML
files, with over-lengthy attributes (some with un-necessary and
over-complicated namespacing to boot ;-). Parsing that lot takes a very
considerable chunk of startup time, and storing redundant foo in memory
seems a bit un-necessary :-)

What does this:

  
 
  

win us over:

  
 
  

? :-) Certainly the latter can be stored as an extra boolean.

Given that we can trivially produce the symbol name from the
implementation name at run-time ? [ if we even need to produce it at all
- since we can link that at compile time ? :-].

I guess - if this would only ever be used for bits of code that are
going to be in the main mergelibs domain & thus could be directly linked
and evaporated away at compile time: and assuming that we subsequently
avoid those being registered in services.rdb I guess it's no issue:
beyond lots more typing, and scope for typos/errors :-)

I suspect though that mergelibs will not encompass all components
though, and that thus we'll end up with lists of this duplication around
the place still (?).

ATB,

Michael.

-- 
 michael.me...@collabora.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Matúš Kukan]

On Mon, 2013-12-23 at 18:44 +0100, Matúš Kukan wrote:
> > ** when compiling .cxx files for which it is known that the constructor 
> > function for some S will be visible (which could e.g. be ~always the 
> > case when compiling for a single big executable on Android/iOS), define 
> > the LO_URE_CTOR_ENV_ and LO_URE_CTOR_FUN_ macros, either via -D 
> > or via some strategically included header
> 
> Yes, so this needs some thought.
> If I see correctly, there are already some typos in
> 15abebbde560e17413f17b16b8b2e9c1f31f01a5
> like LO_URE_CTOR_FUN_com_dot_sun_dot_star_dot_xml_dot_sax_dot_FastParser
> vs.
> LO_URE_CTOR_FUN_com_dot_sun_dot_star_dot_comp_dot_extensions_dot_xml_dot_sax_dot_FastParser

Oh - it's not a typo. We use service name in
codemaker/source/cppumaker/cpputype.cxx - Do we know also implementation
names in codemaker for services?

--
Matus

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Stephan Bergmann]

On 12/23/2013 06:44 PM, Matúš Kukan wrote:

On Thu, 2013-12-19 at 10:51 +0100, Stephan Bergmann wrote:

* assume all LO-internal C++ implementations are ComponentContext-based
(i.e., use cppu::createSingleComponentFactory or
cppu::createOneInstanceComponentFactory rather than legacy
ServiceManager-based cppu::createSingleFactory or
cppu::createOneInstanceFactory); reaching this state is effectively an
easy hack


Yep, but maybe we don't need special easy hack for this.
So far, I was able to just remove the variables as unused.
I think it's easy to do as part of creating constructor function for
implementation.


Not sure what you mean here with "remove the variables as unused."


* implementations of non-single-instance services can be rewritten using
the new .component XML http://cgit.freedesktop.org/libreoffice/core/commit/?id=ae3a0c8da50b36db395984637f5ad74d3b4887bc>
"Add .component 

Hm, what does it mean, it no longer uses css.lang.XInitialization
protocol?
What to do about implementations inheriting from XInitialization?
I tried to convert such class in
https://gerrit.libreoffice.org/#/c/7186/


Yes, using the XInitialization protocol inside the constructor function 
is a possibility here.



* idea is to set aside for every UNO service/singleton S two macros
LO_URE_CTOR_ENV_ and LO_URE_CTOR_FUN_, and a macro
LO_URE_CURRENT_ENV, and modify cppumaker to generate constructor code as


#if defined LO_URE_CURRENT_ENV && defined LO_URE_CTOR_ENV_ \
 && defined LO_URE_CTOR_FUN && LO_URE_CURRENT_ENV == 
LO_URE_CTOR_ENV_

extern "C" cppu::ConstructorFunction_type LO_URE_CTOR_FUN;


Is not LO_URE_CTOR_ENV_ redundant ?
We can just check for defined LO_URE_CTOR_FUN ?


Not in general.


** when compiling .cxx files for which it is known that the constructor
function for some S will be visible (which could e.g. be ~always the
case when compiling for a single big executable on Android/iOS), define
the LO_URE_CTOR_ENV_ and LO_URE_CTOR_FUN_ macros, either via -D
or via some strategically included header


Yes, so this needs some thought.
If I see correctly, there are already some typos in
15abebbde560e17413f17b16b8b2e9c1f31f01a5
like LO_URE_CTOR_FUN_com_dot_sun_dot_star_dot_xml_dot_sax_dot_FastParser
vs.
LO_URE_CTOR_FUN_com_dot_sun_dot_star_dot_comp_dot_extensions_dot_xml_dot_sax_dot_FastParser


Ach, sure, that quick-n-dirty include/osl/detail/component-defines.h is 
just nonsense; it erroneously uses implementation names instead of 
service names for those LO_URE_CTOR_{ENV,FUN}_ macros.



Unfortunately I can't see how to avoid these macros, so I'll try to
generate include/osl/detail/component-defines.h early in build process.
Do you have another idea ?


Introducing include/osl/detail/component-defines.h was just a quick and 
dirty hack to get this bootstrapped.  Ultimately, we likely will not 
want to have those



#if defined ANDROID || defined IOS //TODO
#include 
#endif


lines in the generated .hpp files anyway, but I do not have any more 
concrete ideas yet than that hand-waving "either via -D or via some 
strategically included header" (same for the "the encoding of 
environments (which are normally strings) in LO_URE_CURRENT_ENV and 
LO_URE_CTOR_ENV_ macros must be such that they can be used in the 
preprocessor == expression above" issue).


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Stephan Bergmann]

On 12/23/2013 08:28 PM, Michael Meeks wrote:

On Mon, 2013-12-23 at 18:44 +0100, Matúš Kukan wrote:

* implementations of non-single-instance services can be rewritten using
the new .component XML http://cgit.freedesktop.org/libreoffice/core/commit/?id=ae3a0c8da50b36db395984637f5ad74d3b4887bc>


I'm concerned that we already have way too many, far too verbose XML
files, with over-lengthy attributes (some with un-necessary and
over-complicated namespacing to boot ;-). Parsing that lot takes a very
considerable chunk of startup time, and storing redundant foo in memory
seems a bit un-necessary :-)

What does this:

   
  
   

win us over:

   
  
   

? :-) Certainly the latter can be stored as an extra boolean.


There is a mismatch between the grammar for UNO implementation names and 
C function identifiers usable for these constructor functions, and the 
constructor argument in its current form caters for that.


Note 1:  Of course, "given that we control the [relevant] impl names, we 
[could] simply mandate that they are legal C function names to begin with."


Note 2:  "In addition to having [the components data] stored as XML 
files that are parsed at start-up in cppuhelper::ServiceManager::init, 
one could optionally have them pre-compiled into some data structure 
that is accessible from cppuhelper/source/servicemanager.cxx."


Note 3:  A key insight is that "we can easily extend the components XML 
schema, even removing features again in a later LO version."  First make 
it work, then make it fast (if necessary).


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Michael Meeks]

On Mon, 2014-01-06 at 16:45 +0100, Stephan Bergmann wrote:
> > ? :-) Certainly the latter can be stored as an extra boolean.
> 
> There is a mismatch between the grammar for UNO implementation names and 
> C function identifiers usable for these constructor functions, and the 
> constructor argument in its current form caters for that.

Is there a practical example of this anywhere ? and/or can we not
default to doing the efficient thing and have the casual bloat version
as a fallback ? ;-)

> Note 1:  Of course, "given that we control the [relevant] impl names, we 
> [could] simply mandate that they are legal C function names to begin with."

Are the impl. names not exposed to the scripter / programmer ?

> Note 2:  "In addition to having [the components data] stored as XML 
> files that are parsed at start-up in cppuhelper::ServiceManager::init, 
> one could optionally have them pre-compiled into some data structure 
> that is accessible from cppuhelper/source/servicemanager.cxx."

Sure; so - if we have that data around in a structure, it'd be great
not to duplicate it in the XML and also in the C++ :-) it'd be nice to
have the strings in one DSO only - if we even need them at all :-) [ are
they just a mapping detail ? ].

> Note 3:  A key insight is that "we can easily extend the components XML 
> schema, even removing features again in a later LO version."  First make 
> it work, then make it fast (if necessary).

Sure - my concern is that before we push this across the code-base,
it'd be nice to rid ourselves of the factory functions and come up with
something that is efficient, minimal, as simple as possible, and -then-
push it over a thousand+ call-sites / XML entries etc. Rather than for
each small change having to manually re-touch all that lot.

ATB,

Michael.

-- 
 michael.me...@collabora.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Matúš Kukan]

On Mon, 2014-01-06 at 16:26 +0100, Stephan Bergmann wrote:
> On 12/23/2013 06:44 PM, Matúš Kukan wrote:
> > On Thu, 2013-12-19 at 10:51 +0100, Stephan Bergmann wrote:
> >> * assume all LO-internal C++ implementations are ComponentContext-based
> >> (i.e., use cppu::createSingleComponentFactory or
> >> cppu::createOneInstanceComponentFactory rather than legacy
> >> ServiceManager-based cppu::createSingleFactory or
> >> cppu::createOneInstanceFactory); reaching this state is effectively an
> >> easy hack
> >
> > Yep, but maybe we don't need special easy hack for this.
> > So far, I was able to just remove the variables as unused.
> > I think it's easy to do as part of creating constructor function for
> > implementation.
> 
> Not sure what you mean here with "remove the variables as unused."

Sorry, what I meant, is that they can be also "ServiceManager-based" -
if the ServiceManager is not really used.
Like in
http://cgit.freedesktop.org/libreoffice/core/commit/?id=5bf7b06c937ef08478831bc42b344dc96986a881
I've simply removed constructor parameter for EnhancedCustomShapeEngine
So, I think we don't need that easy hack and can do it in one commit
with converting to constructor function together.

Best,

Matus

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Stephan Bergmann]

On 01/08/2014 09:21 AM, Matúš Kukan wrote:

On Mon, 2014-01-06 at 16:26 +0100, Stephan Bergmann wrote:

On 12/23/2013 06:44 PM, Matúš Kukan wrote:

On Thu, 2013-12-19 at 10:51 +0100, Stephan Bergmann wrote:

* assume all LO-internal C++ implementations are ComponentContext-based
(i.e., use cppu::createSingleComponentFactory or
cppu::createOneInstanceComponentFactory rather than legacy
ServiceManager-based cppu::createSingleFactory or
cppu::createOneInstanceFactory); reaching this state is effectively an
easy hack


Yep, but maybe we don't need special easy hack for this.
So far, I was able to just remove the variables as unused.
I think it's easy to do as part of creating constructor function for
implementation.


Not sure what you mean here with "remove the variables as unused."


Sorry, what I meant, is that they can be also "ServiceManager-based" -
if the ServiceManager is not really used.
Like in
http://cgit.freedesktop.org/libreoffice/core/commit/?id=5bf7b06c937ef08478831bc42b344dc96986a881
I've simply removed constructor parameter for EnhancedCustomShapeEngine
So, I think we don't need that easy hack and can do it in one commit
with converting to constructor function together.


Ah, OK.  Sure, sometimes conversion from ServiceManager- to 
ComponentContext-based is rather trivial.


(My remark that "reaching this state is effectively an easy hack" was 
not meant to imply that we must necessarily file an EasyHack issue for 
it, it was more a classification of the task at hand.)


Stephan

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Stephan Bergmann]

On 12/19/2013 10:51 AM, Stephan Bergmann wrote:

* for implementations of single-instance services/singletons, we can:

** either stick with the recently introduced prefix="direct" feature,
where the service manager obtains a factory for them; any instantiated
object instances will continue to be disposed well ahead of exit via
disposing the ComponentContext in desktop::Desktop::DeInit
(desktop/source/app/app.cxx)

** or also use the constructor="..." feature, in which case the
individual constructor functions would need to hold a single instance,
which could postpone that instance's destruction to atexit, with all
dreaded consequences (an option might be to hold the single instance
weakly)

** or use some 

Update:  "True singletons" (i.e., implementations for which a .component 
file lists a ) are always disposed when the component 
context is disposed (see how ComponentContext::disposing, 
cppuhelper/source/component_context.cxx, "dispose[s] all context 
objects" and how cppuhelper::ServiceManager::addSingletonContextEntries, 
cppuhelper/source/servicemanager.cxx, registers all those "true 
singletons" at the component context upon bootstrap).  That makes the 
third option above less attractive, as it would cause double dispose of 
them, once from the service manager and once from the component context 
(not that it would typically be harmful to do a double dispose on a UNO 
object, but still).


And given that "false singletons" (i.e., services that are implemented 
with single-instance factories) are a misfeature and should arguably be 
replaced by "true singletons," I think I see a way out.


Let me experiment a little and stay tuned...

Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Stephan Bergmann]

On 01/16/2014 09:11 AM, Stephan Bergmann wrote:

On 12/19/2013 10:51 AM, Stephan Bergmann wrote:

* for implementations of single-instance services/singletons, we can:

** either stick with the recently introduced prefix="direct" feature,
where the service manager obtains a factory for them; any instantiated
object instances will continue to be disposed well ahead of exit via
disposing the ComponentContext in desktop::Desktop::DeInit
(desktop/source/app/app.cxx)

** or also use the constructor="..." feature, in which case the
individual constructor functions would need to hold a single instance,
which could postpone that instance's destruction to atexit, with all
dreaded consequences (an option might be to hold the single instance
weakly)

** or use some 

Update:  "True singletons" (i.e., implementations for which a .component
file lists a ) are always disposed when the component
context is disposed (see how ComponentContext::disposing,
cppuhelper/source/component_context.cxx, "dispose[s] all context
objects" and how cppuhelper::ServiceManager::addSingletonContextEntries,
cppuhelper/source/servicemanager.cxx, registers all those "true
singletons" at the component context upon bootstrap).  That makes the
third option above less attractive, as it would cause double dispose of
them, once from the service manager and once from the component context
(not that it would typically be harmful to do a double dispose on a UNO
object, but still).

And given that "false singletons" (i.e., services that are implemented
with single-instance factories) are a misfeature and should arguably be
replaced by "true singletons," I think I see a way out.

Let me experiment a little and stay tuned...


So the way out is to distinguish singleton implementations (whose XML 
description lists at least one ) from normal ones (whose 
XML description does not list any 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.


 
"Support for singleton constructor functions" implements the necessary 
machinery in the service manager, and 
 
"Introduce com.sun.star.frame.theGlobalEventBroadcaster singleton" and 
 
"Revert 'Revert 'sfx: Use constructor feature for 
SfxGlobalEvents_Impl''" demonstrate how to apply it to SfxGlobaleEvent_Impl.


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Michael Meeks]

On Thu, 2014-01-16 at 18:52 +0100, Stephan Bergmann wrote:
> So the way out is to distinguish singleton implementations (whose XML 
> description lists at least one ) from normal ones (whose 
> XML description does not list any s), and let the service 
> manager keep track to only create a single instance of those.

It's great to see this all improving =) of course, I'm primarily
focused on as much size reduction and efficiency improvement for mobile
as possible here =) but everything helps.

Thanks !

Michael.

-- 
 michael.me...@collabora.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Stephan Bergmann]

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 ) from normal ones (whose
XML description does not list any 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.


"Support for singleton constructor functions" implements the necessary
machinery in the service manager, and

"Introduce com.sun.star.frame.theGlobalEventBroadcaster singleton" and

"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 
 
"Constructor functions for singletons still need to pass out single 
instances":



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

However, this change:
* postpones the instance's destruction to atexit, with all dreaded consequences;
  lets see how that pans out.
* 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.


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Stephan Bergmann]

Some notes on recent changes around constructor functions:

* The change of 
 
"Minimize the constructor functions to a bare minimum" to let 
constructor functions return un-acquired pointers breaks constructor 
functions that internally already have an acquired pointer.  This includes:


** Constructor functions for singletons, like 
com_sun_star_comp_sfx2_GlobalEventBroadcaster_get_implementation 
(sfx2/source/notify/globalevents.cxx).


** "Wrappers" like those for which constructor functions have been 
reverted again in 
 
"Revert 'svt: Use constructor feature for FilePicker and 
FolderPicker...'" (based on the rationale it "does not make a real sense 
to use constructor for implementations that act as a trampoline," which 
I do not understand).


If the stated rationale for that change is that it is "annoying to see 
the boilerplate copypasted everywhere," I think there is better 
solutions for that, like providing a helper function to be called from 
the typical constructor function,


  css::uno::XInterface * acquire(cppu::OWeakObject * instance) {
assert(instance != 0);
instance->acquire();
return instance;
  }

  css::uno::XInterface * FOO_constructor_function(...) {
retrun acquire(new FOO(...));
  }

* 
 
"Change _get_implementation()'s not to do initialization directly" makes 
it more awkward to code the (assumedly) common case where a UNO service 
constructor with arguments can be implemented directly by a C++ class 
constructor with arguments.  That change forces two-step construction, 
via passing back a member function pointer, onto all such cases, with 
the apparent rationale to make the (assumedly) non-common case that does 
require two-step construction simpler to code.


(And I'm not even sure it is technically correct to force the address of 
a member function of a class derived from cppu::OWeakObject to 
cppu::constructor_InitializationFunc.  Also, for the static_cast from 
XInterface to OWeakObject in servicemanager.cxx to work, this change 
makes the---undocumented---requirement that constructor functions making 
use of the two-step--init callback return an exact one of their 
potentially many XInterface pointers; rather brittle.)


FYI, I envisioned a road where ultimately a (new-style) UNO service's 
different constructors rather directly map to a C++ implementation 
class's different constructors.


* One main reason for introducing those constructor functions in the 
first place is to allow (in specific scenarios) for direct calls of them 
from client code, bypassing the service manager.  I think it is 
beneficial to test that direct-call scenario as much as possible while 
working on this, that is why I created the manual scaffolding of 
osl/detail/component-defines.h. 
 
"Reduce the number of experimental direct constructor calls" reducing 
instead of increasing the number of constructor function implementations 
for which direct-calling will actually be tested is detrimental to that.


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Jan Holesovsky]

Hi Stephan,

Stephan Bergmann píše v St 22. 01. 2014 v 10:22 +0100:

> I think there is better 
> solutions for that, like providing a helper function to be called from 
> the typical constructor function,
> 
>css::uno::XInterface * acquire(cppu::OWeakObject * instance) {
>  assert(instance != 0);
>  instance->acquire();
>  return instance;
>}
> 
>css::uno::XInterface * FOO_constructor_function(...) {
>  retrun acquire(new FOO(...));
>}

Thank you for reviewing! :-)  My problem with directly providing
arguments to the _constructor_function (and consequently to the C++
constructor) was that it was hard to distinguish whether the code
constructing the instance needs to work on an acquired interface, or
not, so thought that if we 'force' every initialization to work on the
acquired one, it leads to least trouble.

But if this is not a problem, and the implementer should be aware & make
the right choice, I am most happy; actually the resulting constructors
look really beautiful from my POV:

https://gerrit.libreoffice.org/7592

Thanks so much for this suggestion - if you are happy with the patch,
I'd push it ASAP to unbreak the Windows build...

All the best,
Kendy

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: 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 ) from normal ones (whose
> > XML description does not list any 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.
> >
> > 
> > "Support for singleton constructor functions" implements the necessary
> > machinery in the service manager, and
> > 
> > "Introduce com.sun.star.frame.theGlobalEventBroadcaster singleton" and
> > 
> > "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 
> 
>  
> "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/"); 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  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

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Matúš Kukan]

On Wed, 2014-01-22 at 10:22 +0100, Stephan Bergmann wrote:
> FYI, I envisioned a road where ultimately a (new-style) UNO service's 
> different constructors rather directly map to a C++ implementation 
> class's different constructors.
> 
> * One main reason for introducing those constructor functions in the 
> first place is to allow (in specific scenarios) for direct calls of them 
> from client code, bypassing the service manager.  I think it is 
> beneficial to test that direct-call scenario as much as possible while 
> working on this, that is why I created the manual scaffolding of 
> osl/detail/component-defines.h. 

Right, makes sense, so I've added some we use from sfx2, svtools, svx in
http://cgit.freedesktop.org/libreoffice/core/commit/?id=a69875fbfcab0c4f0069aeb72079155789c35256
"Experimental direct constructor calls for more services."

Best,
Matus

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: 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/"); 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 
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
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Matúš Kukan]

On Fri, 2014-01-24 at 17:36 +0100, Stephan Bergmann wrote:
> 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."

Ah, ok, now I think I understand :-)

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

Yes, I will add that.

> > And maybe it's a good thing.
> > We could use always context->getValueByName("/singletons/"); 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.

Right, I was confused with disposing, deleting c++ objects etc.
It's proly pointless to explain how, it wouldn't make sense anyway :-)

So, we just need to use true singletons and it will work.

Thanks,

Matus

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Efficient UNO component linkage & GC ...

[Stephan Bergmann]

On 10/08/2013 03:23 PM, Michael Meeks wrote:

** Part one - splitting factories

Clearly we need a new naming scheme for these; this should be
based on a mangled version of the implementation name; so:

   

->

com_sun_star_comp_Draw_GraphicExporter_getFactory();

Despite everyone's loathing of the css. namespace this makes
part three much easier.

There are various ways to annotate that a .component file
eg. svx/util/svx.component refers to a shlib with a split factory. I
suggest we reduce the problem space by asserting that each shlib with
this property has it's components entirely split up - yielding a
single attribute change.

For these we alter the prefix="svx" to prefix="" or
some equivalent magic, and tweak:

stoc/source/loader/dllcomponentloader.cxx:

Reference SAL_CALL DllComponentLoader::activate(
 const OUString & rImplName, const OUString &, const OUString & rLibName,
 const Reference< XRegistryKey > & xKey )

To special case this prefix, and build a symbol name (in
aPrefix) and use a new variant of:

cppuhelper/source/shlib.cxx:Reference< XInterface > SAL_CALL 
loadSharedLibComponentFactory(

To load and hook out the correctly named symbol there.


DllComponentLoader is mostly dead by now, only comes into play during 
live-deployment of (non-bundled) extensions.  And since, as per 
 
"Extension shared library components must not use the 'prefix' feature," 
see 
 
"No need to support 'prefix' in DllComponentLoader."


Handling of the prefix feature is done entirely in 
cppuhelper/source/servicemanger.cxx and cppu::loadSharedLibComponentFactory.


Having reached this point, we basically have two options:

Either, keep with the current design of _component_getFactory 
functions (responsible for returning factories for potentially many 
object implementations, dispatched by name).  To split into smaller, 
unconnected parts would mean to split existing  XML entities 
into smaller ones, each with its own prefix attribute (but potentially 
multiple ones with the same uri attribute), and to split exisiting 
_component_getFactory function definitions into smaller ones 
accordingly (but keeping their structure).  That way, a 
_component_getFactory could still be responsible for either 
multiple or just a single object implementation (though in the latter 
case would incur somewhat more overhead than a more straightforward 
design), and we would need no modifications to the infrastructure.


Or, as you detail below, go further and add more efficient support for 
the "single-object-implementation" factory case.  (Do you have any idea 
whether this is worth it, given we have to continue supporting the other 
case for extension-compatibility anyway?)


Anyway, given that the current "prefix" feature should only be used by 
internal code we have under full control (see recent discussion 
elsewhere on this mailing list), should we go down that road, I'd prefer 
to replace the existing "prefix" feature with something new (e.g., an 
extension of the components XML schema that associates an individual 
 rather than a  with a prefix attribute), 
rather than keeping both.  (Though we could support both for a 
transition period while we incrementally update the existing code.)



We also define these factory functions to always be passed a
valid pServiceManager, and only ever to be asked to construct the
exact service name mangled into the symbol, hence:


SAL_DLLPUBLIC_EXPORT void * SAL_CALL 
com_sun_star_drawing_SvxUnoColorTable_getFactory ( void * pServiceManager )
{
 // Ideally this reference, and the branch below would be subsumed
 // by a helper, such that this method call was a single line, and
 // ideally could be macro-ized elegantly.

 uno::Reference< lang::XSingleServiceFactory > xFactory;

 xFactory = cppu::createSingleFactory(
  reinterpret_cast< lang::XMultiServiceFactory * >( 
pServiceManager ),
  SvxUnoColorTable::getImplementationName_Static(),
  SvxUnoColorTable_createInstance,
  SvxUnoColorTable::getSupportedServiceNames_Static() );
  if( xFactory.is())
  {
 xFactory->acquire();
 return xFactory.get();
  }
  return NULL;
}


Not sure what that specific step buys you in comparison to keeping with 
the existing


  extern "C" SAL_DLLPUBLIC_EXPORT void * SAL_CALL
  _component_getFactory(
  char const * name, void * serviceManager, void * registryKey)

interface (which is already "always [...] passed a valid 
pServiceManager," and always ignores the long-time legacy registryKey 
argument) and just ignoring the name argument in the 
"single-object-implementation" case.


What would likely be more entertaining i