Threading issues?

[N.C. Wilson]

I was thinking about something said in an e-mail a few days ago.

On Thursday 03 January 2008 1:33 am Leo Franchi wrote:
> Just an FYI, it is not good to save the return value of Amarok::config
> (IIRC, due to threading isues).
> So the first "fix" doesn't really work :)
> Otherwise, this patch looks good.

The code in question was this: - QList<int> cats = Amarok::config( 
"Collection Browser" ).readEntry( "TreeCategory", QList<int>() ); + 
KConfigGroup config = Amarok::config( "Collection Browser" ); + QList<int> 
cats = config.readEntry( "TreeCategory", QList<int>() );

I was doing this to save re-creating the 'config' object when it is used a 
few lines later. I accept what was said, but I can't see _why_ it should 
make a difference. In the first version, a temporary is made, which acts 
just the same as in the next line. Temporaries have constructor/destructor 
calls and are treated exactly like normal objects (except they are 
immediately destructed, not left on the stack until the end of the scope). 
If it is unsafe to call readEntry on a KConfigGroup object, then the thread 
could be interupted here:

                                -----> <-----
Amarok::config( "Collection Browser" ).readEntry

just as easily. If any locking is being done, it must either be in the 
constructor or the call itself, both of which are the same. Unfortunately, 
the class uses internally a QExplicitelySharedDataPointer, which seems to 
be undocumented in Qt4. Can anyone explain why the change is unsafe?

Nicholas