Re: Efficient UNO component linkage & GC ...

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 > > alw

Re: Efficient UNO component linkage & GC ...

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

Re: Efficient UNO component linkage & GC ...

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 functi

Re: Efficient UNO component linkage & GC ...

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 s

Re: Efficient UNO component linkage & GC ...

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

Re: Efficient UNO component linkage & GC ...

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 c

Re: Efficient UNO component linkage & GC ...

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

Re: Efficient UNO component linkage & GC ...

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

Re: Efficient UNO component linkage & GC ...

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 i

Re: Efficient UNO component linkage & GC ...

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

Re: Efficient UNO component linkage & GC ...

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::c

Re: Efficient UNO component linkage & GC ...

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 >

Re: Efficient UNO component linkage & GC ...

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 ar

Re: Efficient UNO component linkage & GC ...

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>

Re: Efficient UNO component linkage & GC ...

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

Re: Efficient UNO component linkage & GC ...

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_CT

Re: Efficient UNO component linkage & GC ...

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 concer

Re: Efficient UNO component linkage & GC ...

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::createOneInstanceComponentFacto

Re: Efficient UNO component linkage & GC ...

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

Re: Efficient UNO component linkage & GC ...

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 c

Re: Efficient UNO component linkage & GC ...

> 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 neve

Re: Efficient UNO component linkage & GC ...

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_get

Re: Efficient UNO component linkage & GC ...

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 publi

Re: Efficient UNO component linkage & GC ...

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

Re: Efficient UNO component linkage & GC ...

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

Re: Efficient UNO component linkage & GC ...

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 installat

Re: Efficient UNO component linkage & GC ...

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/se

Re: Efficient UNO component linkage & GC ...

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