Threading issues?

[Dan]

Not to hijack this topic or anything... but omg its Untouch!

Alexandre Oliveira wrote:
> That guideline was added because once we faced a very hard to debug
> problem that was caused by something like this:
>
> KConfigGroup config = Amarok::config( "some group" );
> (...)
> someMethodThatUsesAmarokConfigWithOtherGroup();
> (...)
> int someInt = config.readEntry( "someOption", 0 );
>
> However, by looking at the name of the method it wasn't any obvious
> that it used Amarok::config().
>
> On 05 Jan 2008 14:42:09 +0000, N.C. Wilson <ncw33 at cam.ac.uk> wrote:
>   
>> On Saturday 05 January 2008 3:11 am Leo Franchi wrote:
>>     
>>> On Jan 4, 2008, at 5:31 PM, N.C. Wilson wrote:
>>>       
>>>> 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?
>>>>         
>>> i can't exactly explain why, but there is an example in HACKING with a
>>> code sample that *should* work but doesn't, and it explains why. so
>>> you might want to look there.
>>>
>>> leo
>>>       
>> Thank you.  The problem is not that there is some other thread that could
>> barge in and modify your object before you use it, but rather it is just a
>> good habit to save you from yourself when you modify the code later.  The
>> code I gave then does work, but reduces maintainability because it is not
>> clear that the two lines must immediately follow each other.
>>
>>
>> Nicholas
>> _______________________________________________
>> Amarok mailing list
>> Amarok at kde.org
>> https://mail.kde.org/mailman/listinfo/amarok
>>
>>     
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok
>