Hi Stephan,
indeed we have a problem to transport the adjusted command line
arguments to the starting script/executable. Till now the problem has
affected the crash-recovery restart only, since it was the only scenario
that has triggered the office restart. The problem is solvable, but it
was not recognized as important enough to get attention, there are
enough problems that are much more important.
I am currently not sure, what exactly is done for the Bundled extensions
before restart, but I suspect that the configuration is accessed. That
means that the IPC-thread must already run at this point.
If my understanding is correct, I must confess, that I do not see an
atomic solution for the problem currently. The current behavior (
IPC-thread starts before the restart ) looks for me as the lesser evil,
since the probability of the scenario is very small ( I am in doubt that
we ever get it without writing a special script for this ), and even if
it happens, it still prevents the concurrent access to the configuration.
If I misunderstand something and there is a better solution, I would of
course support it.
Best regards,
Mikhail.
PS: As far as I understand, if IPC-thread starts and creates pipe after
accessing the configuration, it will not enlarge the dangerous time
span, it will create it, since currently the IPC-thread is started at
the very beginning, before the configuration is accessed.
On 05/12/10 16:54, Stephan Bergmann wrote:
I see the following problem with the implementation of
<http://qa.openoffice.org/issues/show_bug.cgi?id=108704> "Need UNO
service for restarting the office process" in combination with its use
in the implementation of
<http://qa.openoffice.org/issues/show_bug.cgi?id=77196> "Bundled
extensions":
108704 makes available a service that shuts down the running soffice
process and restarts it with the same command line arguments it was
originally started with. (At least, that is my understanding from
glancing at the code.)
77196 wants to make use of that service to decide, during soffice
start, whether changes to bundled extensions require an immediate
soffice restart.
A starting soffice opens two kinds of connection acceptors. For one,
it starts an inter-office "IPC" connection
(desktop/source/app/officeipcthread.cxx), used to make sure that only
one soffice process is ever running for a given user at a given point
in time (presumably to avoid chaos in the UserInstallation), and
additionally started soffice processes for that user connect to the
initial process and pass their command line arguments to the initial
process, which then handles them. For another, it starts URP
connection endpoints for all the "-accept" arguments passed in on the
command line.
It is important in which order the three events (77196-restart,
accepting "IPC", and accepting "-accept") happen during startup.
Accepting "-accept" should come after 77196-restart (otherwise, there
would be the problem of an external process connecting to the first
soffice instance, only to immediately afterwards loose its connection
again when soffice restarts). This is the easy part.
The problem is with the ordering of accepting "IPC" and 77196-restart.
If accepting "IPC" happens before 77196-restart, a second soffice
process can pass its command line arguments to the first instance of
the first, accepting soffice process, which then restarts and thus
forgets about the command line arguments from the second process. The
net effect for the user is that his second soffice invocation
(requesting to open a specific document, or to accept on a specific
UNO endpoint) appears to have no effect.
If accepting "IPC" happens after 77196-restart, this enlarges the time
span in which multiple soffice processes for a single user can run
concurrently, potentially causing chaos in the UserInstallation.
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@framework.openoffice.org
For additional commands, e-mail: dev-h...@framework.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@framework.openoffice.org
For additional commands, e-mail: dev-h...@framework.openoffice.org
