https://bugs.documentfoundation.org/show_bug.cgi?id=157841
--- Comment #1 from Ashod Nakashian ---
Hi!
What is the expectation of calling LOKit from multiple threads? That it will
execute those calls faster? That editing will be done in parallel?
Unfortunately, that can't work. The API calls and commands sent to LOKit must
still execute in a single thread inside Core. There is no way to parallelize
that, since the document model is not concurrent.
This means that the only sensible thing to do here is to add locks on all the
API, so that calls from different threads block each other and get exclusive
access. This would work in your case, but then it would penalize all other
cases that design the LOKit usage based on the Core threading model, which is
single-threaded. In other words, it would add complexity and slow down the
normal case.
That is, normally, you want to handle multi-threading (if necessary) elsewhere,
and serialize the access to LOKit. Since document modifications are done
sequentially anyway, it's a good idea to issue those commands/calls in order as
well. Notice that Undo will also be sensible, as you'd know what change the
Undo will do (it will be in the reverse order of the change commands/calls).
If, for whatever reason, you cannot change your design of having multi-threaded
input, then the sensible thing to do is to make the LOKit reference exclusive.
That is, the threads need to call an API to get the LOKit reference, which of
course uses a lock to pass the reference from one thread to the other. If the
lock is taken, it means the reference is not available.
TL;DR; adding locks in every API is very costly, when there are simpler
solutions.
Thank you.
--
You are receiving this mail because:
You are the assignee for the bug.
