> (OK, working on this, but I'm fixing data races in Qt and bugs in helgrind > along the way, so it will take a bit more time.)
That's ok - I'm don't have time to use it at the moment. >> Originally I was thinking the big lock, which, most of the time, was >> already held by >> the ResourceData method that called addToWatcher, but then I thought of a >> way to avoid the lock being taken in the ResourceData method, so we can't >> do that anymore :) > > "the ResourceData method" -- did you mean load()? > >> So I added an extra mutex for the ResourceWatcher, but I'll switch it >> to the single-thread stuff you suggest. > > OK. > > In general I'm backing down a bit from "let's not use the big lock", though: > I'm working on fixes so that it's not held for long (i.e. not during socket > communication), so locking it for fast operations is fine. I have some fixes for that too...I'll post them this evening (US time, ie, in about 5 hours). Basically it is no longer held during setProperty all the time. At the moment what I did with the watcher was make the calls happen in one thread, and protect initialisation of m_watcher with the initMutex (which becomes a ReadWriteLock). Do you think it is faster to use moveToThread, or protect it with a mutex? >> hmm, this is more tricky - we need to safely access >> m_watcher->resourceCount() somehow, >> although I think I see a way around that... > > I think start and stop should simply be done inside the implementation of > addResource/removeResource. This would solve the problem completely. > Anything else is racy. Agreed :) - what I did was to add two functions that started and stopped the ResourceWatcher, as well as adding and removing the resource, because I didn't want to change the behaviour of add/removeResource in a stable release. Thanks for the patches, which I will try to review and test this evening. Simeon _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
