thomassc abandoned this revision.
thomassc added a comment.
Okay, thanks for your feedback. Discarding this then. I think I might have
found the problematic access in KDevelop already in the meantime ...
REPOSITORY
R39 KTextEditor
REVISION DETAIL
https://phabricator.kde.org/D23721
To: t
dhaumann added a comment.
KTextEditor is nowhere designed to be thread-safe. Even if this patch solves
a particular issue you have in multithreaded access, we can be sure there will
be other (corner?) cases where it won't work: Think only of modifying the text
at some other place at the same
thomassc added a comment.
Okay, I wasn't aware of the overall situation wrt. threading. Still, couldn't
it be useful to at least allow for concurrent read accesses which is probably
not a large effort (in contrast to concurrent read and write)? I guess that
people might not expect blockForLi
cullmann added a comment.
Hmm, the use of atomic + a local var might avoid that the compiler optimizes
away the local var and just uses m_lastUsedBlock again directly, but I am not
sure if we should go that way.
If one has concurrent accesses to the buffer from different threads, all is
lo
thomassc edited the summary of this revision.
thomassc added a reviewer: KTextEditor.
REPOSITORY
R39 KTextEditor
REVISION DETAIL
https://phabricator.kde.org/D23721
To: thomassc, #ktexteditor
Cc: kwrite-devel, kde-frameworks-devel, LeGast00n, GB_2, domson, michaelh,
ngraham, bruns, demsking,
thomassc created this revision.
Herald added projects: Kate, Frameworks.
Herald added subscribers: kde-frameworks-devel, kwrite-devel.
thomassc requested review of this revision.
REVISION SUMMARY
In the "shortcut: try last block first" branch in TextBuffer::blockForLine(),
m_lastUsedBlock is a