Threading issues?

[Alexandre Oliveira]

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
>