I forgot to mention in the commit message of
2fab757462 what error situation the
change fixes... So here goes:
If a client session closes just after sending a load message to load a
document, and another session then fairly immediately connects and
sends a load message for the same document, the latter session gets
handled by the same kit process. Also the same Document object is
apparently used. In that kit process, the documentLoad() can still be
in progress. The handler for the new session still calls onLoad(),
too, and as the onLoad() had dropped the lock for the duration of the
documentLoad() call, the new onLoad gets the lock and calls
documentLoad(), too, while the documentLoad() call in the other thread
still is in progress. This leads to interesting problems.
Actually, now that I think of it, I very much doubt it is sane to have
the same Document object used for several sessions (one or several
already "dead" ones and one "live" one) simultaneously, but at least
the change made the unit test work more reliably.
The callbacks from documentLoad() are made in the same thread.
Sure, as such it is not a good thing to use recursive mutexes. If we
switch back to non-recursive mutexes, we will have to stop taking the
lock in callbacks from documentLoad(), i.e. make sure we know those
functions aren't used elsewhere, in places where a lock would be
needed. Or something.
... and Admin and AdminModel containing all the required data
that we need to expose to Admin panel.
Admin processor will keep listening to any data on this
notification pipe and update AdminModel accordingly.
Change-Id: I0dd6f07ae60158733c34d17f53a35def70600513
Reviewed-on: https://gerrit.libreoffice.org/22780
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
It does quite a lot of work that can produce very many lines of log,
so it is good to be able to quickly find when that is done when
perusing a log file.
Not needed after all. It was a red herring. The device files work fine
even if not owned by root:root and with mode 664. The actual problem
was that I used a file system mounted with nodev when testing loolwsd.
This reverts commit 509314d559
That is probably what was the intent. As originally written, in case
the function encountered partial writers, and had to do several
write() calls, only the number of bytes written by the last one was
returned.
Luckily the actual return value of writeFIFO() is not used
anywhere. It is just tested for being negative.
Still there is the problem that if at first one or several write()
calls succeed but don't write the whole buffer, and then a write()
fails, the caller has no way to know that the buffer has been
partially written. But that is hopefully highly theoretical and there
is no sane way to handle such a situation anyway.
The getChildStatus() and getSignalStatus() functions returned the
latter, still the returned values were compared against
Poco::Util::Application::EXIT_OK. (Sure, both Poco's
Application::EXIT_SUCCESS and stdlib.h's EXIT_OK are zero, but that
doesn't mean one should mix them up.)
Also add two comments pondering the meaning of the code.
We are not interested in the variable being assigned an incremented
value. Its value is not used any more. We are just interested in the
value of the variable plus one. Using pre-increment gives the wrong
impression.
Sure, this is nit-picking.
So don't give it any then.
Remove the --uid option and related attempts to handle running loolwsd
under sudo, to be able to debug it. Now with loolwsd not having
capabilities, it should work fine to just run it under a debugger
normally. (For the loolbroker and loolkit processes, attaching to an
already started process is the way to debug.)
One has to love arbitrary retry counts and timeouts. Loading the
password-protected.ods in a loolkit process, with correct password
provided, takes 12 seconds on my machine. I think this slowness is
because the NSS code LO uses to do crypto wants to initialize its
crypto goodness in various ways that don't work so well inside a
chroot jail. Presumably it uses some wait with timeout when attempting
to do something which doesn't succeed. For instance it tries to run
netstat -in. (In an interactive LibreOffice the doc loads fairly
instantly.) Oh well.
