Tile invalidation is a hint to the clients to request
fresh tiles and replace the existing ones. However
any outstanding tile request will be rendered anew.
So no need to remove those.
Nonetheless, we should issue new versions to avoid
race between old tile and invalidate. This can
happen when a tile rendered just before invalidate
reaches the client after the invalidate. The client
will think the tile is a new one when it was rendered
just before the invalidate.
Change-Id: Ieb2ffab1214dd904da8e532e7d9d20e6ad783b78
Reviewed-on: https://gerrit.libreoffice.org/29123
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
I wanted to try loolwsd built with _GLIBCXX_DEBUG defined and thus
needed cppunit built like that, too. (And Poco, but we already had
configury to point to a self-built Poco.)
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>
Extending the document URL with debug=1 option will switch
- visible tile boundaries
- update numbers over tiles
and invalidated tiles will be blue during waiting for an update.
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?)
It can return null for no obvious reason, leading to misleading
logging where the same thread is identified as numer zero at one place
and non-zero at another. So use the actual Linux thread id in logging.
Sure, thread ids are somewhat less convenient, as they are larger
numbers, from the same number space as process ids.
Editlock buttons have already been removed; most of this code is
unreachable/useless anyways.
Don't listen to editlock messages anymore, and always set the map
permission to edit unless specified.
Change-Id: I2ee672e72beaa48a7c6cd0bbd1c548ff10a251d1
Tile queue was used to process canceltiles commands.
Since those are handled by TileCache, there is no need
for queues and the threads that pump them.
But because these queues were also used to buffer between
WSD internals and clients, such that a slow client wouldn't
block WSD while sending back tiles, it is necessary
to reword that logic.
In subsequent commits that will change as well.
With this change not only do we save a thread per client,
but we also reduce latency of tile, and improve typing
responsiveness, by almost 3x or more! Latencies are
down to ~15ms from almost 50ms.
Reviewed-on: https://gerrit.libreoffice.org/28575
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
(cherry picked from commit 59eaacd2f8)
Change-Id: I77813267a95a724491165792ec020ae00953c05e
Reviewed-on: https://gerrit.libreoffice.org/29066
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
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>
This reduces chances of data loss and gives
more up-to-date data to the user.
Also include tile messages in the trace recording,
since they are useful for debugging. Should be
disabled to reduce excessive trace generation.
Change-Id: I223144660698843f4e94564e049883db898c0064
Reviewed-on: https://gerrit.libreoffice.org/29060
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.
