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:
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
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
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
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,
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
