When upon cleanup we segfault we want to avoid
forcible exit using _Exit(). This was done by
an unconditional wait (sleep).
This patch changes that mechanism into a latch
(mutex) that traps the exit when the sig handler
is invoked, therby preventing exit as long as
necessary for the sighandler to finish.
Change-Id: Ifc8e972be12645a1b310d4cb4e3a4172afc31327
Reviewed-on: https://gerrit.libreoffice.org/29945
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
No need to do a partial cleanup in the kit
when forkit recycles the disk. This avoid
both programatic errors (as the comments in
the removed code explains) as well as hammering
the disk from multiple processes.
By leaving all disk cleanup to forkit we
guarantee safety and that only one process
does disk cleanup, and sequentially at that.
N.B. Kit processes are still responsible for
setting up the jail and the LO binaries etc.
So disk IO is not strictly sequential from a
single process.
Change-Id: Ia6768ab87df71a83a6676c3d52da3d6797f717fc
Reviewed-on: https://gerrit.libreoffice.org/29944
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
And a few other minor fixes. No need to create an std::string object
when a char number is enough, nor need to copy an object when passing it
by reference is enough.
Change-Id: I3d6aba20ffce781532ea77fe079ce64378db6e12
Using a new internal command, when a client disconnects
an internal 'disconnect' message is dispatched so
the child process cleans up the ChildSession in question.
Change-Id: I34166ad59e84ae389a3913bd2430fe537225bb4b
Reviewed-on: https://gerrit.libreoffice.org/29650
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Which is sometimes stored in a bool, but when auto is used, it's char*,
so it helps to have that written explicitly.
Change-Id: I561692e8d5c575b4ff8612fd50e489ad3c60d655
This minimizes unlocking and relocking
on the LOK Document.
Change-Id: Ibe5045c82008df907dc329c1530cb50138b0c211
Reviewed-on: https://gerrit.libreoffice.org/29545
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
By default LOK doesn't provide the part where the invalidated
tile is. The part # is found using API, but due to the fact
that callbacks are processed asynchronously, the part #
may well have changed by the time the invalidation is
processed. This could result in buggy invalidations
where no modification took place.
With the new API flag LOK_FEATURE_PART_IN_INVALIDATION_CALLBACK
the part # is included in the callback, which is parsed
and used to inform the client with the correct part #.
Change-Id: Ibd85764bfdc41ebf1aae490df335bd503284ae91
Reviewed-on: https://gerrit.libreoffice.org/29467
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Instead of trying to inform the sysadmin (which we did not yet try to
do in any meaningful way), inform all connected clients (even those
editing other documents).
We use 'error: cmd=internal kind=diskfull' as the message to the
clients. The loleaflet code needs to be updated to handle that
carefully by displaying a very prominent message that tells the user
that all bets are off.
Also add a unit test for the functionality.
Document the new protocol details.
The code for this alert functionalty became a bit less elegant than I
like because of the way we include Util.cpp in the unit test 'test'
program.
Still need to add code to check for disk full in more places, not just
when saving a cached tile or font. Probably we should even actually
check for disk space on the file system(s) we use getting alarmingly
low, not just check for file writing operations that fail. Later.
The missing init of mutexes is probably theoretical, the TraceFile and
the Unit ones were real errors, I think.
Change-Id: If19c23a9c93d34059998346af8d45c26a34043a6
Instead of 2 queues and 2 threads, merge those to one - which gives a perfect
ordering of the invalidations and rendering.
Change-Id: I229dfc08b43e6ce7e4f08ea8059d3298d9bf8f8a
Reviewed-on: https://gerrit.libreoffice.org/29282
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
This replaces addview/remview/remallview messages in the protocol
with 'viewinfo' message which is sent whenever there is any
change in the view information.
Let the client deal with what information is redundant to it.
Change-Id: Ic470ea88a94ff281a0ae021014a9fba1b876f648
On destroyView Core must flush the events queue, otherwise
by the next idle the descriptor will be gone and we'll
be using freed memory.
Change-Id: I6d3d8f9461bc156383a7294e9c65c535d79f2e7a
Reviewed-on: https://gerrit.libreoffice.org/29088
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Seems to fix the deadlock problem, or at least makes it very much
rarer. (I am not entirely certain that a callback might not be in
progress already (in another thread) when we turn off callbacks, and
in that case the callback might still then access freed memory?)
If the connection thread is not running when loading a
document, the callback will drop events. This can happen
when the thread is too slow to spawn, but we return from
the createSession function and process client messages.
This should solve the race where we lose notifications of
other views when a new view is created.
Change-Id: Ia79739889b2f01fbb374d48eb33620084f4ed1c1
Reviewed-on: https://gerrit.libreoffice.org/29063
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Act as if it was always set.
The ChildSession::_multiView field will always be true, so factor it
out. Ditto for Document::_multiView.
The ClientSession::_haveEditLock will also be always true, so factor
it out. This means the ClientSession::isEditLocked() will always
return true, so factor it out, too.
ClientSession::markEditLock() always will always set _haveEditLock to
true (which it will be from the constructor already anyway) so it can
be removed.
ClientSession::setEditLock() does not need a parameter as the
parameter was actually only used for misleading logging. The msg
variable constructed in the function used isEditLocked(), not the
parameter.
We still generate and handle editlock messages. Not sure whether that
makes any sense, though.
