-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105562/
-----------------------------------------------------------
(Updated Sept. 6, 2012, 4:40 p.m.)
Review request for Nepomuk, Vishesh Handa and Sebastian Trueg.
Changes
-------
Completely reworked the fix, so that the RM mutex is held before calling
determineUri, and so that no AB/BA deadlocks happen: the rule is that the RM
mutex must never be locked after the modificationMutex.
It's either modification alone, or RM and then modification.
I had to move some code from RM to RD, because RM was using data->m_cache
directly, without locking data's mutex first!
This new code is not only more threadsafe (no helgrind warning anymore in my
tests) but also much better object-oriented, RM is no longer accessing RD's
private data directly.
Description
-------
Fix race conditions in nepomuk's ResourceData.
Found with "helgrind kmail --nofork", inbox, clicking on any email.
where helgrind is "QT_NO_GLIB=1 valgrind --tool=helgrind --track-lockorders=no"
The change in resource.cpp avoids a deadlock due to the change
in resourcedata: no need to hold the rmMutex for the determineUri call.
This addresses bug 295802.
http://bugs.kde.org/show_bug.cgi?id=295802
Diffs (updated)
-----
libnepomukcore/resource/resourcedata.h 7e185a7
libnepomukcore/resource/resourcedata.cpp c14582f
libnepomukcore/resource/resourcemanager.cpp 2a6668a
Diff: http://git.reviewboard.kde.org/r/105562/diff/
Testing
-------
Thanks,
David Faure
_______________________________________________
Nepomuk mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/nepomuk
