[Nepomuk] Nepomuk Core - Questions & Patches

Vishesh Handa handa.vish at gmail.com
Sun May 23 14:28:28 CEST 2010


Hey Sebastian

least one problem: run the resourcetest and see it crashing. This is due
> to determineUri deleting "this". determineUri() is called all over the
> place. I think the one solution is to move that call into Resource as I
> already did with store().
>

I had no idea there were tests. For some reason I totally missed them! I was
going to write my own tests to validate the patch.

Anyway, you're right. It crashes. The problem is that replaceWith(..)
deletes itself. And then determineUri tries to access the m_uri variable.
Even if we simply "return true", from determineUri(). It is called all over
the place and hence some other member function accesses its, no longer
valid, member variables. (Your explanation wasn't clear enough!)

There is one more problem. I can't always reproduce it. Before
replaceWith(..) is called the ResourceManager's mutex is locked. Then when
deleting it self resetSelf(bool) attempts to lock the mutex. The locking
sometimes fails, and it just keeps waiting.

One way of solving both the problems is to derive ResourceData from QObject.
And then call deleteLater() instead of "delete this". (Patch attached)

*Random Question:* In determineUri()'s last if condition -

if( !m_uri.isEmpty() ) {
            QMutexLocker rmlock(&m_rm->mutex);

            ResourceDataHash::iterator it =
m_rm->m_initializedData.find(m_uri);
            if( it == m_rm->m_initializedData.end() ) {
                m_rm->m_initializedData.insert( m_uri, this );
            }
            else {
                // As the ResourceData already exists in m_initializedData,
we simply
                // make all the the Resources which contain "this"
ResourceData, point
                // to the initialized ResourceData instead.
                replaceWith( it.value() );
            }
        }

Couldn't we move the MutexLocker inside the if( it ==
m_rm->m_initializedData.end() ) ?

- Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20100523/c7c5e881/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.diff
Type: text/x-patch
Size: 16334 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/nepomuk/attachments/20100523/c7c5e881/attachment-0001.diff 


More information about the Nepomuk mailing list