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