On 06/17/2013 12:35 PM, Thomas Voß wrote:
> On Mon, Jun 17, 2013 at 10:02 AM, Michael Zanetti
> <michael.zanetti@canonical.com> wrote:
>> Basically instead of launching your app normally, you give it as an argument
>> to a the so called invoker (/usr/bin/invoker) which has all the common stuff
>> already loaded and forks to your application.
To be precise: /usr/bin/invoker just takes the application name and
parameters and sends them to applauncherd (via a socket). Applauncherd
has *already* forked into a new "empty" process, which is just waiting
for the invoker data to load the application.
So, what is left to do is just the application loading -- the forking is
already done.
> Ack, here is where the upstart-launcher would come into play.
I don't know much about upstart, but my understanding is that the
functionality of the /usr/bin/invoker (it's a very small process) could
go into upstart-launcher.
[...]
>> to create a new QApplication. I don't exactly know the details what they do
>> inside that MDeclarativeCache. I guess one thing is to monitor the state of
>> the created QML view and make the splash screen go away when ready.
>>
>
> This is something we would need to investigate further. Alberto, can
> you take a look at MDeclarativeCache and try to summarize the benefits
> it provides?
I think I explained it in my other message (point 2), but I'll try to be
more clear: the booster process, which is the "empty" process waiting
for a connection from the invoker to load the real application binary,
is linked (or has dlopen()ed) quite a few common libraries, and has
already instantiated a QGuiApplication and a QQuickWindow. This means
that all the initializations performed by QGuiApplication (don't ask me
what it does, I have no idea :-) ) and QQuickWindow (this is quite
heavy: it initializes the QQmlEngine, and consequently the javascript
engine) are already done by the time that the user starts an application.
What happens when the user starts an application, is that the invoker
informs the booster process of what binary needs to be loaded. The
booster process sets up the security context and loads the real
application binary, then invokes its main() method (with proper argc and
argv), and all works.
Now, to take the pre-initialization into use, the application binary
needs not to instantiate new QGuiApplication and QQuickWindow, but just
obtain them from the booster (which provides a couple of static
functions to retrieve the already instantiated objects).
Note that the objects which we want to pre-load are completely up to us.
Suppose that we found out that there's another class whose
initialization time is quite consistent, we can have the booster
pre-create it (if the object's constructor takes no arguments, or if we
can provide them later). Likewise, an application is not forced to use
our cached objects; indeed, there might be cases where they don't work
(the QApplication doesn't work with more than 32 command line arguments,
for instance), so corner cases are covered as well.
Please read the two links from my initial post (especially the second
one); I think they explain the feature much better than how I could do. :-)
Ciao,
Alberto
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
