[Nepomuk] nepomukqueryservice and its client model(s)

David Faure faure at kde.org
Thu Jul 12 15:44:49 UTC 2012


On Tuesday 10 July 2012 17:30:47 Vishesh Handa wrote:
> On Mon, Jul 9, 2012 at 7:18 PM, David Faure <faure at kde.org> wrote:
> > On Monday 09 July 2012 16:53:31 Vishesh Handa wrote:
> > > I don't think it's a threading problem cause m_initMutex is locked
> > > before
> > > deleting it, and before accessing it.
> > 
> > That doesn't help. MainModel::executeQuery gets a pointer to a ClientModel
> > inside the lock, and then return an iterator which keeps using that
> > ClientModel outside the lock (or its ClientConnection, more precisely).
> 
> Yes, but the iterator which it receives is of type
> Soprano::Client::ClientQueryResultIterator. This iterator just contains an
> iterator id, and a pointer to the model. Before each operation performed on
> the iterator, it check if the model pointer is not null .. aha!
> 
> The pointer will always be 'not null'.
> 
> > So this opens the door for crashes, whenever the code that deletes the
> > model
> > is run.
> 
> So you're right, we cannot delete the model.
> 
> Or maybe we could use some kind of pointer wrapper which check for
> deletions. I'm not sure if Qt provides this. Either way it seems messy.

I thought a bit more about this, and a pointer wrapper would still need a 
mutex for concurrent access, so in the end, we'd have an object that contains 
the pointer and the mutex, and we would never know when to delete that object 
itself, i.e. back to square one :-)

But in fact, thinking about it more --- the whole issue is that we use the 
same "client model" in all threads, and that is precisely the reason why all 
queries are serialized.

How about using one client model per thread?
(i.e. per query, if I understand this correctly -- or hopefully this is a 
threadpool where threads are reused for future queries?)

This could be done without changing the API, simply by using a QThreadStorage 
in the code that creates and returns client models.
If this makes sense from an overall design point of view (I have no idea what 
a client model actually is, how expensive it is to create, etc.), then I can 
make that patch.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5



More information about the Nepomuk mailing list