rjvbb added a comment.
In https://phabricator.kde.org/D6376#119376, @cullmann wrote: > Next try ;=) > Question is, can really such a race happen, that finishNotification triggers duplicate insertion? Do you see any other explanation why a crash could occur under qDeleteAll, one that is due to a bug in KNotifications and not in Phonon itself? I'd say the source for a duplicate insertion (and thus the location of the race condition) would be a concurrent execution of `m_reusablePhonons.takeFirst()`, where more than 1 thread gets hold of the same item. > At least with a hash set, this won't lead to later issues. Why not use a barrier or lock to ensure that the `takeFirst()` requests are executed one by one? FWIW, a race condition wouldn't only lead to duplicate entries in the list (something I'd hope Qt knows how to handle) but also to more than 1 thread using the same Phonon object at the same time. Who's to tell what state that object will be in? REPOSITORY R289 KNotifications REVISION DETAIL https://phabricator.kde.org/D6376 To: cullmann, #frameworks Cc: mpyne, rjvbb
