LibreOfficeKit and the UserInstallation

A LO UserInstallation must not be accessed concurrently by multiple 
processes (at least not when at least one of them potentially modifies 
it).  LO itself ensures that with the first soffice instance listening 
on a well-known pipe (whose name depends on the UserInstallation path, 
among other things), and any subsequently started ones dispatching their 
command line arguments to that first one (the "OfficeIPCThread" code, 
desktop/source/app/officeipcthread.hxx).

I don't know how LOK wants to ensure that, though.

One obvious approach is giving different processes different (throwaway) 
UserInstallations.  There is code that sets the UserInstallation 
bootstrap variable in LOK's lo_initialize (desktop/source/lib/init.cxx) 
when the passed-in pUserProfilePath is non-null.  However, tracing back 
the callers of lo_initialize:

* smoketest/libtest.cxx calls lok_preinit with a null user_profile_path
* sal/android/libreofficekit-jni.c calls libreofficekit_hook (implicitly 
passing null)
* ios/experimental/TiledLibreOffice/TiledLibreOffice/AppDelegate.m and 
libreofficekit/source/gtk/lokdocview.cxx call lok_init (implicitly 
passing null)
* libreofficekit/qa/tilebench/tilebench.cxx, 
libreofficekit/qa/unit/tiledrendering.cxx, and smoketest/libtest.cxx 
call lok_cpp_init with a (defaulted) null pUserProfilePath

That is, not overriding the default UserInstallation seems to be 
encouraged rather than being prevented when using LOK.

The next line of defence happens to be that LOK apparently bootstraps 
enough of the LO code to make the OfficeIPCThread code come into play, 
cf. 
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=5ffdcea247f64e36f56cfbfa3ba2bde0777945d6> 
"Use OfficeIPCThread::WaitForReady rather than sleeping" etc.

However, "happens to" because that OfficeIPCThread code is rather a mess 
that, in addition to the pipe stuff explained above, also is central to 
LO's lifecycle management.  And it is rather this second part that LOK 
is interested in.  Or, rather, that it needs to get its head wrapped 
around, as the LO code that LOK bootstraps somewhat unhelpfully insists 
on getting the OfficeIPCThread code involved---all that the LOK code 
apparently wants is to be notified once the LO code is bootstrapped, and 
OfficeIPCThread::WaitForReady happens to be a convenient way to get that 
done.

I think LOK would be better off not starting off that OfficeIPCThread 
pipe listening stuff at all.  (It is most certainly not intended that 
soffice and non-soffice LOK processes happily pass their command line 
arguments to each other for processing.)  And 
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=d61c7573d7345a3b57a9e71740ff8f50ee40116e> 
"Add a comment" appears to agree with me on that.

I got dragged into this when trying to untangle the OfficeIPCThread 
mess.  Running LO under xdg-app will require to optionally use DBus 
instead of a named pipe in the OfficeIPCThread code, but adding that is 
unnecessarily difficult with the current state of the code.  So, while 
at it, I thought I could just as well see to get LOK's unwanted 
dependency on OfficeIPCThread removed.

Therefore, I would like somebody overseeing the architecture of LOK to 
explain how LOK intends to solve its "multiple processes per 
UserInstallation" problem.