Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


Hi Stephan,

On Wed, Mar 23, 2016 at 03:30:50PM +0100, Stephan Bergmann <sbergman@redhat.com> wrote:
Therefore, I would like somebody overseeing the architecture of LOK to
explain how LOK intends to solve its "multiple processes per
UserInstallation" problem.

There are two main use-cases for LOK at the moment: Android and Online.

In the Android case there can't be multiple processes using LOK. If a
document is opened and a second document would be opened, then the OS
takes care of forwarding this request to the already running app. So no
need for the OfficeIPCThread stuff, we just want to know when
LibreOffice startup is ready. As you already saw, lo_initialize() uses
it to wait till LibreOffice starts up (on the "soffice thread" that's
the main thread in the desktop case), but if there is an other way to
get notification about when startup is ready, that's also fine.

In the Online case, LOK is initialized in a process that runs in a
chroot, and it always gets an empty user profile (that was the need to
introduce a custom profile location in the LOK API initially). Given
that we just create the user profile, we can be sure that nobody else is
using it: so again just lo_initialize() uses the OfficeIPCThread stuff.

So as far as I'm aware, in both main use cases, we just assume that the
user profile is not used by anyone else (either because the OS kind of
gives a guarantee for that, or because the profile path is a unique one
we just created), that's why there is no explicit code handling that.

You're right that in case you use LOK on the desktop, e.g. via
<https://github.com/ojwb/lloconv>, and soffice is already running, then
we have a problem -- this situation is not handled at the moment, so
whatever rework would be needed for xdg-app, you can ignore this case.

Wrt. killing the OfficeIPCThread stuff, as long as lo_initialize() is
adapted so that it uses some other reliable way to determine when LO
started up, it doesn't need it, either. If the LOK startup logic needs
debugging, then either the in-tree gtktiledviewer or the above lloconv
is probably the easiest tools to trigger that code: both Android and
Online are complex to set up, and relatively complex to debug as well.

[ In case a precise definition is needed for "started up", I guess what
we really assume there is:

1) comphelper::getProcessComponentContext() returns something
meaningful.

2) Global services like css.frame.Desktop are available.

It seems these are true after OfficeIPCThread::WaitForReady() returns. ]

Regards,

Miklos

Attachment: signature.asc
Description: Digital signature


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.