buffer: Add proper lock mechanism to lock the full LineArray instead of single lines
#3224
Conversation
JoeKar
force-pushed
the
fix/line-synchronization
branch
2 times, most recently
from
ffe83d8 to
b47fa04
Compare
JoeKar
force-pushed
the
fix/line-synchronization
branch
3 times, most recently
from
dc6da7b to
c359c8d
Compare
|
The execution time of the test increases (for me) from ~10ms to ~100ms, so it's round about ten times slower now. |
I see the same, but I believe it increases just because of uncommenting BTW you can run some actual benchmarks, by running |
This is necessary as a preparation to introduce a lock for the whole LineArray. The modification can then be done without trying to lock the same lock twice. Co-authored-by: Dmytro Maluka <dmitrymaluka@gmail.com>
...which isn't used so far and probably handled better in a different way.
This is achieved by the usage of the new `LineArray` locking machanism, which prevents the interruption in the moment of modifications like insertion or removal of lines. Co-authored-by: Dmytro Maluka <dmitrymaluka@gmail.com>
...since we fixed the race between the syntax highlighting and the buffer editing.
JoeKar
force-pushed
the
fix/line-synchronization
branch
from
c359c8d to
a3ca054
Compare
Ah, yes...the initial highlighting is affecting the execution the most and has the most impact at |
|
Just for others' information: #3220 contains the discussion & investigation which has led to this PR. |
The PRs #3062 and #3208 in combination revealed a long existing race problem which manifested itself (after the merge of the PRs) sporadically in the MacOS tests, which failed.
The reason for the fail usually is the access of the async highlighter code (triggered by
UpdateRules()) to lines which don't exist any longer, since they're already removed by the testing code.With the fine tuning of #3220 we should be able to catch such situations earlier...at least when they are caused by builtin functionalities.